EP0915445A2 - System zur Ermittlung von Verkehrsinformationen - Google Patents

System zur Ermittlung von Verkehrsinformationen Download PDF

Info

Publication number
EP0915445A2
EP0915445A2 EP98118423A EP98118423A EP0915445A2 EP 0915445 A2 EP0915445 A2 EP 0915445A2 EP 98118423 A EP98118423 A EP 98118423A EP 98118423 A EP98118423 A EP 98118423A EP 0915445 A2 EP0915445 A2 EP 0915445A2
Authority
EP
European Patent Office
Prior art keywords
data
traffic
unit
information
message
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.)
Granted
Application number
EP98118423A
Other languages
English (en)
French (fr)
Other versions
EP0915445A3 (de
EP0915445B1 (de
Inventor
Wilhelm Derenne
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.)
Siemens AG
Original Assignee
Siemens AG
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=7844692&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP0915445(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Siemens AG filed Critical Siemens AG
Priority to DK98118423T priority Critical patent/DK0915445T3/da
Publication of EP0915445A2 publication Critical patent/EP0915445A2/de
Publication of EP0915445A3 publication Critical patent/EP0915445A3/de
Application granted granted Critical
Publication of EP0915445B1 publication Critical patent/EP0915445B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions

Definitions

  • the invention relates to a system for determining Road routes, in particular traffic information related to motorways.
  • DE-P 44 08 547 describes a method for traffic detection and traffic situation detection on highways, preferably Motorways, known.
  • Cross sections are set up for track-related measuring points, with traffic sensors, such as induction loops, for vehicle detection and with a traffic data processing device are provided.
  • traffic data such as vehicle speed, traffic volume and traffic density determined and from this determined traffic parameters in one Traffic data processing formed.
  • Each form two neighboring measuring points a measuring section with a certain Track length. From the traffic data of two such measuring points traffic parameters are formed.
  • These are one Speed density difference, calculated from local traffic data medium speed and traffic density, a trend factor, determined over a certain period of time the ratio of the traffic volumes of both measuring points as well a traffic intensity trend.
  • Using a Fuzzy logic the probability of a critical traffic situation derived. When a probability threshold is reached can then be a control signal for a Variable message signs are generated.
  • detectors are also known, which Presence and the speed of a moving object can capture.
  • detectors work According to a passive infrared process, which can also be used with other methods can be combined.
  • No method is known to date, traffic information covering the entire area to record and evaluate. Especially no methods are known to determine the traffic information route section variable, event-oriented if necessary and enable with little data transfer effort.
  • a low data transmission effort is on the one hand Implementation of an energy-saving process required on the other hand, as transparent and easy to maintain as possible Generate databases.
  • the present invention is based on the object of providing a comprehensive traffic information system which, with simple sensors and low data transmission effort, provides reliable and sufficiently meaningful data bases for different traffic information services.
  • the technical solution of this object a system for determining stretches of road, in particular motorways, related traffic information, each with at least one detection unit, one input data communications unit, a data processing unit for generating signaling records, a message management unit for conditioning signaling records, an output data communications unit is proposed with the invention, for sending information to distributors and a visualization unit for displaying information.
  • the system according to the invention is thereby advantageous further developed that this recorded an archive for and / or processed information, a system monitoring unit, a data flow monitoring unit, a data processing monitoring unit as well as, if applicable Has time control unit for monitoring message sequences.
  • the visualization advantageously takes place using window technology and the system includes a dialog mask system.
  • the invention discloses a system for determining on Road routes, especially motorways, related traffic information, using local detectors Acquisition cross-sections formed, traffic-related measured values recorded, preprocessed by means of local computers and on a Predefined data protocol standardized, aggregated and by radio transferred to a higher-level data processing system become.
  • the invention enables the implementation of a step organized acquisition and processing system. Thereby can different traffic models to different Levels are applied, some of which are local, some of which are central. The advantages are that short term results can be achieved by expanding into the individual Levels are consolidated and refined. Through the dissolution there is a high level in individual subtasks or levels Degree of flexibility and reliability through the Formation of fallback levels. Through the local pre-analysis of the Traffic gives rise to extremely energy-saving, event-oriented data transmission to the parent Data processing systems or centers.
  • the invention proposes that fixed detectors positioned at junctions, nodes and the like become. It is also proposed that the Arrangement density of the fixed detectors depending is determined by traffic expectation estimates. So leave through the arrangement of many local detection systems Build comprehensive networks. It is also with the invention possible to organize an overall network structure. On traffic technology local detectors and critical positions Preprocessing computer arranged, preferably via radio in digital technology the data to higher-level data processing systems forward or control centers. There you can then other traffic models are applied to the data.
  • Adjacent local detection cross sections can be a so-called route-related level of service in a higher-level Data processing system or one of the entire network assigned headquarters are determined.
  • Measured data After a detector, for example a passive infrared detector, Measured data are delivered, they will be preprocessed, for example by calculating mean values, Plausibility checks and trend factor determinations carried out become. From the changes in the data or the data state codes themselves are then determined, for example in the form of a numerical value for conditions such as free traffic flow, Traffic jam, stop and go, traffic jam or standstill etc. Evaluation cycles can, for example, every 1 to 5 minutes to get voted. However, the evaluation cycle can be variable be determined, for example depending on the status codes or the traffic conditions. The same applies the data transfer rate, which depends, for example of the determined status code is used, for example one transmission every 30 minutes when traffic is free with averaging every 5 minutes. Depending on the fault condition the transmission density can be increased. In doing so the data transfer rates of adjacent acquisition cross sections matched to each other.
  • a detector for example a passive infrared detector
  • Measured data are delivered, they will be preprocessed, for example by calculating mean values, Plaus
  • the measured values can be recorded in relation to the lane, but what is not absolutely necessary, other detection cross sections can also be used To be defined. It is also fundamental possible, vehicle type differentiation values, for example Detect trucks, cars and the like.
  • the invention proposes that superordinate data processing systems at least for those grouped together neighboring detection cross sections can be assigned.
  • a control center can act as a higher-level data processing system for all detection cross sections of a network or for several higher-level data processing systems can be assigned.
  • the network organization can be done in whatever stages flexibility and data security are affected. Here economic parameters can be used as a boundary condition become.
  • source-to-target relationships by analyzing the data of all acquisition cross sections of a network determines that the data for route search, evaluated for the output of traffic management information, subjected to statistical analysis for clarification and that the data for making traffic development forecasts be evaluated.
  • the invention provides a system for different Types and qualities of traffic information data to provide.
  • the main task is to provide such data to prepare for the motor vehicle driver and this provide appropriate information.
  • It can be for example, travel time displays, route displays, traffic forecast, Act traffic jams and the like.
  • information displays arranged on which the motor vehicle driver their planned routes and travel time information are displayed to get. You can then, for example, under different Alternatives choose the fastest route. Additionally or alternatively, indications of traffic jam developments, Probabilities related to further development on the upcoming route section and the like are displayed.
  • the range of applications is extensive.
  • the invention provides an extremely flexible system, with which by linking different traffic models an almost network-wide, nationwide Traffic information system is buildable, which data for provides a wide variety of information purposes. It can be conventional and already known models and processes are used and be combined. Forecasts can be curve-based Forecasts at measuring points, model-based forecasts for Sections and meshes and additions of immeasurable effects using artificial intelligence. For the calculation Standard formulas of average values are used.
  • the system can be supplemented by systems that are dependent on the time of day Standard additional information, for example time of day and route-related travel time information, bring in.
  • a central traffic computer is installed for traffic data acquisition, traffic data archiving, traffic data visualization and analysis of the traffic situation.
  • An X25 connection for data transmission with a Modacom network is installed for this.
  • the control center receives the data of the external measuring points via this data connection.
  • the hardware of the control center consists of a PC as a communication computer for the interface to the Modacom network (X25 / Modacom) and a workstation as a traffic and visualization computer.
  • the aforementioned computer components are interconnected in a LAN.
  • An X25 connection is provided for data transmission with the outstations (traffic detection).
  • Data telegrams are identified by data type numbers, Applications through system-unique application and computer numbers.
  • In the distribution table is stored for a data type to which applications it should be sent.
  • the application is used for data flow control. She gets via the distributor the data telegrams, their data flow to monitor is. Which is stored in the parameterization file Data types in which time grid should be monitored.
  • the actions that are carried out (sending a telegram), if the receipt of a telegram e.g. for one Measuring cross-section longer than the associated time grid fails to appear, are in another file, according to Actions for the reporting system and the visualization separately parameterized, defined.
  • sending a telegram if the receipt of a telegram e.g. for one Measuring cross-section longer than the associated time grid fails to appear, are in another file, according to Actions for the reporting system and the visualization separately parameterized, defined.
  • the reporting system a message telegram is sent, based on the missing data type indicates and specifies for the specific measuring cross section, how long it has not been received.
  • the advantage of data flow control is that of data flow monitoring, already related to by the communication module the aggregation module is done that way the telegrams via the distributor and thus the communication system is also monitored.
  • the computer time is set daily by a radio clock driver and one connected to a serial interface Radio clock synchronized.
  • the cron is the central point of the UNIX system to kick off cyclical applications.
  • the time when which Application or UNIX batch file is to be executed, is parameterized in a separate file for each UNIX user.
  • the message converter mekonv selects from those of the message system generated telegrams with messages those that a Statement about the accessibility of an aggregation module do.
  • the messages are converted into special telegrams and sent to the visualization (via the distributor), so that the state in the detailed information about measurement cross sections and sections can be viewed. Every message is repeated cyclically (approx. every 15 minutes) so that after restarting the visualization after some time current States can be displayed.
  • the communication module is for data transfer between the Modacom server on the gateway computer and the others Components of the central computer, as shown in Figure 2 is shown.
  • the Modacom server of the gateway computer handles independently communication with the Modacom network via Datex-P / X.25. It provides the data received from the aggregation modules, reduced by appropriate protocol information about which TCP / IP socket interface available to the communication module.
  • the communication module has the following tasks:
  • the traffic data is sorted according to AM-ID, the one in the data block Acquisition time and DE an acquisition interval assigned and saved in the internal data image.
  • AM-ID the one in the data block Acquisition time
  • DE an acquisition interval assigned and saved in the internal data image.
  • DE no the assigned measurement cross section determined.
  • the AM After a configurable time (e.g. 11 minutes) If no data is received from an AM, the AM is called noted and reported unusual.
  • a configurable time e.g. 11 minutes
  • the status of the DE contained in the data block is stored in the internal Image carried. Results from the data received a change, it will be with a telegram data type Error status of the lanes.
  • the communication module also reports the status every hour to the reporting system for comparison of the message image with the internal image.
  • the status of the ASIM detectors, which they report to the SiAM and is also contained in the status byte, is used by the communication module prepared for a message and sent to the message manager Posted.
  • the communication module After the communication module has started up, it sends to everyone AM a query telegram to determine the traffic-related AM parameters and status identifiers when the first received telegram of an AM is not a status telegram. The for further processing see 'Status data of an AM'.
  • Modacom server Operating reports and news about Modacom and TCP / IP connections are logged on the Modacom server. Only Modacom-specific are connected to the communication module Messages about the delivery of a data packet to a SiAM modem passed on.
  • the raw traffic data received is made more traffic-related Process evaluated.
  • the goal is the investigation selected traffic parameters.
  • the evaluation takes place in three separate stages. The steps differ in the complexity of the methods used and thus in the quality and type of the calculated traffic parameters.
  • the recorded traffic data are recorded on the online system processed two ways.
  • the Raw data manipulated by a module for single-track simulation shown in Figure 4
  • the raw simulation data generated in this way are then evaluated in parallel with the online data. Online and simulation area of the traffic models work independently of each other.
  • the input values of all stages are the measured values of the detection cross sections.
  • Traffic model level 1 (shown in Figure 5)
  • the missing MQ values are not interpolated. The model then works as if this MQ does not exist in the system. If the missing MQ is the only one in a section the section is therefore treated as a section without MQ.
  • Traffic model level 2 (shown in Figure 6)
  • the missing MQ values are not interpolated. The model then works as if this MQ does not exist in the system. If the missing MQ is the only one in a section the section is therefore treated as a section without MQ.
  • Level 3 traffic model (shown in Figure 7)
  • Section is the distance between two nodes. Segment "is a part of the distance between two measuring cross sections.
  • ESE extended situation detection
  • ESE refers to sections that range from measuring cross-section to measuring cross-section.
  • These variables are transferred to sections of the route which relate to the area between two nodes.
  • the message manager shown as a structogram in FIG. 8 is for the receipt, processing and transfer of responsible messages that are sent from processes to the message system become. It serves as the central administrative office of Data that the operator and observer the correct or incorrect Show working of the system.
  • the message texts to be output are defined by the message number and parameters for the replacement of actual parameters in a base defined by message texts in the message text file.
  • the message manager consists of the message preparation components (MEAU) and message distribution (MEVT). Between these The MESALOG message log system is connected between applications, that is responsible for the preparation of the message texts is.
  • MEAU accepts the message telegrams from the applications the SIPAX BW.KOM interface and prepares them contained actual parameters for the transitions to MESALOG on.
  • MEVT feeds the finished message texts for further processing into the system.
  • the visualization serves to present the results online of the various models for determining the travel time bands (Cruising speed in the section) and densities Display of detailed information of the sections and measuring cross sections, as well as to display traffic and operational reports.
  • the process image is created when the visualization is started and with the static information from the runtime files provided.
  • All data sent during operation for visualization are stored by the PAM in the process image.
  • the process image is kept in a shared memory. All processes resulting from this pool of information and data need this shared memory in their address space involve.
  • Named pipes are used for inter-process communication within the visualization system: Pipe Define source aim description appl_to.dapo Q_APPL_DAPO PBM DAPO Start telegram appl_to.gui Q_APPL_GUI PAM, MEM GUI Update, notifications appl_to.mem Q_APPL_MEM all applications MEM internal visualization messages gui_to.pbm Q_GUI_PBM GUI PBM Start telegram dapi_to.pam Q_DAPI_PAM DAPI PAM Telegrams in internal format
  • the input telegrams are converted into the internal data format and the net data are object-related in the process image filed.
  • the update is triggered by an update Graphic process (GUI) informed about the new data. Messages are passed on to the GUI as plain text.
  • GUI Graphic process
  • the input data are visualized in the following form:
  • the assigned route section is colored with the color set for error detection.
  • the error status is displayed in the detailed info mask.
  • the raw traffic data is displayed in the detailed info dialog mask alphanumeric (table) and graphic (Traffic data recorder) shape is displayed. Is the info mask appears when new data is received, the display is updated.
  • the message text is in the message line and the message overview entered for operating messages. Is the message as A receipt form is also marked with a receipt faded in. Is the parameterized number message window opened at the same time is reached newly arriving messages requiring acknowledgment are buffered. The next message is only after acknowledgment of a message displayed from the buffer.
  • the message text is in the message line and the message overview entered for traffic reports. Is the Message marked as requiring a receipt will be added a receipt form is displayed. Is the parameterized Number of simultaneously opened message windows reached, this way, newly arriving messages requiring acknowledgment are buffered. Only after acknowledging one message is the next one Message from the buffer displayed.
  • the data is alphanumeric Shape. Is the info mask when new data is received is displayed, the display is updated.
  • the assigned section in the overview displays "Travel speed standard” and “Density standard” is colored according to the set threshold values and color codes.
  • the data is displayed in the detailed information mask in alphanumeric form. If the info mask is displayed when new data is received, the display is updated.
  • the archive receives data and message telegrams via message queue and writes them to archive files, which are stored in the so-called Archive area "of the hard disk.
  • a backup mechanism is activated via cron, which compresses the data of the previous day.
  • the data compressed in the can be saved on DAT tape.
  • the backup is initiated manually by the operator.
  • the following types of data are processed by the archive.
  • the results of the single-track simulation are under own Data types sent.
  • the archive differentiates based on the data type in which archive area a data record is to be archived is.
  • the lane acquisition of traffic data is done by feeding of manipulated raw data simulated (see Figure 10). To a lane is selected for each MQ from the recorded data, from whose data the traffic data of the total cross-section be extrapolated. The data set determined in this way is distributed to the traffic models and processed there. The Processing of the extrapolated data in the traffic models does not differ from the processing of online data.
  • Archived data can be read in on an offline computer and fed back to the traffic models (see figure 11).
  • the processing differs in the traffic models not from processing in the online case.
  • the time range to be simulated is controlled by a sequence control module selected. Operation of the offline simulation is controlled at the shell level.
  • An X-Window System is a graphical standardized window system and thus an international defacto standard for UNIX systems. It is a computer and operating system independent Window system with graphical user interface, that the simultaneous work with several processes enables. It is color graphics capable, works object-oriented and mouse supported.
  • the interface is divided into a menu bar, two interaction areas and a message line. Via the menu bar the operator selects the individual graphical representations, Call up detailed information, display messages etc. In one Interaction area, the results of each procedure represented graphically. In the message line the last incoming traffic or operational message displayed.
  • the representation in an interaction area takes the form a schematic overview in Figure 12 of the highway network in the Cologne / Bonn area.
  • the highways are in the area of the test area divided into sections based on the incoming data are colored gradually.
  • a map can be shown in the background of the interaction areas (menu item Graphics ⁇ Map ).
  • the display can be based on data from full-track recording or based on single-track simulation.
  • the display of Simulation data is obtained by coloring the heading of the corresponding interaction area.
  • the currently set threshold values can be displayed via the menu item Graphics ⁇ Legend ... Threshold values and color codes are defined in the application resource file.
  • symbols for displaying traffic incidents are shown at the corresponding points. The symbols show an unrest / traffic jam detection (from level 2) and a situation number (from level 3). Symbols for traffic disruptions that result from data from the full-track detection are only displayed in the graphics for the original data. Symbols for faults due to simulation data are shown in the graphics for the online simulation. A direct comparison is therefore possible.
  • the symbols are structured as shown in Figure 13:
  • a section is defined by the so-called "Rubber banding". With the help of the mouse, a rectangle is created around the desired image section. The defined one Section is then shown enlarged.
  • a pop-up menu appears on the screen at the current position of the mouse pointer.
  • the enlargement or reduction factor is the zoom factor set in the graphic / layout mask.
  • For the sensitive objects in the overview displays can be selected with the left or right mouse button each in connection with a modifier key (SHIFT or CTRL) Additional information can be called up.
  • a short info on Object can be obtained by clicking with the right mouse button without using a modifier.
  • the results of the various models for determining travel speeds and densities are visualized by coloring the corresponding sections of the route.
  • the input data are divided into stages based on threshold values. After selecting this menu item, a mask shown in FIG. 15 is displayed in which the currently set color codes and threshold values are displayed.
  • Operating messages are messages about detected device faults, i.e. External system malfunctions or internal system errors.
  • the operator receives important messages in a manner shown in FIG presented message dialog for confirmation.

Landscapes

  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)
  • Closed-Circuit Television Systems (AREA)
  • Selective Calling Equipment (AREA)

Abstract

System zur Ermittlung von auf Straßenstrecken, insbesondere Autobahnen, bezogene Verkehrsinformationen, mit jeweils wenigstens einer Erfassungseinheit, einer Eingangsdatenkommunikationseinheit, einer Datenverarbeitungseinheit zur Erzeugung von Meldesätzen, einer Ausgangsdatenkommunikationseinheit zur Informationsversendung an Verteiler sowie einer Visualisierungseinheit zur Informationsdarstellung. <IMAGE>

Description

Die Erfindung betrifft ein System zur Ermittlung von auf Straßenstrecken, insbesondere Autobahnen bezogene Verkehrsinformationen.
Im Stand der Technik ist es bekannt, an einzelnen Meßstellen Verkehrsflußinformationen zu erfassen, um daraus direkte Störinformationen abzuleiten oder Verkehrsentwicklungsprognosen für benachbarte Streckenabschnitte zu entwickeln. Es sind jeweils nur Einzellösungen bekannt.
Beispielsweise ist in der EP 0 256 483 A1 ein Verkehrsleit- und Informationssystem offenbart, welches unter Verwendung ortsfester Leitbaken und in Fahrzeugen angeordneten Sende- bzw. Empfangseinheiten Verkehrsflußinformationen ermittelt. Aus diesen Verkehrsflußinformationen werden insbesondere Störinformationen ermittelt, um Leitsignale zu schalten.
Aus der DE-P 44 08 547 ist ein Verfahren zur Verkehrserfassung und Verkehrssituationserkennung auf Autostraßen, vorzugsweise Autobahnen, bekannt. Zur Bildung von sogenannten Meßquerschnitten werden spurbezogene Meßstellen eingerichtet, die mit Verkehrssensoren, beispielsweise Induktionsschleifen, zur Kfz.-Detektion und mit einer Verkehrsdaten-VerarbeitungsEinrichtung versehen sind. Es werden regelmäßig Verkehrsdaten wie Kfz.-Geschwindigkeit, Verkehrsstärke und Verkehrsdichte ermittelt und daraus bestimmte Verkehrskenngrößen in einer Verkehrsdatenaufbereitung gebildet. Dabei bilden jeweils zwei benachbarte Meßstellen einen Meßabschnitt mit einer bestimmten Streckenlänge. Aus den Verkehrsdaten zweier solcher Meßstellen werden Verkehrskenngrößen gebildet. Diese sind eine Geschwindigkeitsdichte-Differenz, berechnet aus lokalen Verkehrsdaten mittlerer Geschwindigkeit und der Verkehrsdichte, ein Trendfaktor, ermittelt über einen bestimmten Zeitraum aus dem Verhältnis der Verkehrsstärken beider Meßstellen sowie ein Verkehrsstärketrend. Aus diesen Daten wird mittels einer Fuzzylogik die Wahrscheinlichkeit für eine kritische Verkehrssituation abgeleitet. Bei Erreichen eines Wahrscheinlichkeitsschwellwertes kann dann ein Steuersignal für ein Wechselverkehrszeichen erzeugt werden.
Im Stand der Technik sind auch Detektoren bekannt, die das Vorhandensein und die Geschwindigkeit eines bewegten Objektes erfassen können. Beispielsweise arbeiten derartige Detektoren nach einem Passiv-Infrarot-Verfahren, welches ggf. auch mit anderen Verfahren kombiniert werden kann. Im Stand der Technik ist bisher kein Verfahren bekannt, flächendeckend Verkehrsinformationen zu erfassen und auszuwerten. Insbesondere sind keine Verfahren bekannt, die die Verkehrsinformationsermittlung streckenabschnittsbezogen variabel, ggf. ereignisorientiert und mit geringem Datenübertragungsaufwand ermöglichen.
Ein geringer Datenübertragungsaufwand ist einerseits zur Durchführung eines energiesparenden Verfahrens erforderlich, andererseits um möglichst transparente und leicht pflegbare Datenbestände zu erzeugen.
Unter der Bezeichnung Bundesautobahnsystem Unix
Figure 00020001
BABSY/X" ist von dem Unternehmen Siemens zu Testzwecken ein Verkehrsbeeinflussungssystem installiert worden. Dabei wurden im Abschnitt der A9 zwischen dem Autobahnkreuz Neufahrn und dem Autobahnkreuz München-Nord eine Reihe von Detektoren in Form von Induktionsschleifen angeordnet und die erfaßten Werte online ausgewertet, um die aktuelle Streckenbelastung zu ermitteln. Diese wurden dann grafisch in unterschiedlichen Farben dargestellt, wobei die Farben einen Zustandscode darstellen. Das System erstellte Kostenanalysen für unterschiedliche Schaltzustände und war schließlich in der Lage, eine Linienbeeinflussungsanlage zur Darstellung unterschiedlicher Wechselverkehrszeichen und Fahrtempfehlungen anzusteuern.
Ausgehend von diesem Stand der Technik liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein flächendeckendes Verkehrsinformationssystem bereitzustellen, das mit Einfachsensorik und geringem Datenübertragungsaufwand zuverlässige und hinreichend aussagekräftige Datengrundlagen für unterschiedliche Verkehrsinformationsdienste bereitstellt.
Zur technischen Lösung dieser Aufgabe wird mit der Erfindung vorgeschlagen, ein System zur Ermittlung von auf Straßenstrecken, insbesondere Autobahnen, bezogene Verkehrsinformationen, mit jeweils wenigstens einer Erfassungseinheit, einer Eingangsdatenkommunikationseinheit, einer Datenverarbeitungseinheit zur Erzeugung von Meldesätzen, einer Meldungsmanagementeinheit zur Aufbereitung von Meldesätzen, einer Ausgangsdatenkommunikationseinheit zur Informationsversendung an Verteiler sowie einer Visualisierungseinheit zur Informationsdarstellung.
In vorteilhafter Weise ist das erfindungsgemäße System dadurch weitergebildet, daß dieses ein Archiv für erfaßte und/oder verarbeitete Informationen, eine Anlagenüberwachungseinheit, eine Datenflussüberwachungseinheit, eine Datenverarbeitungsüberwachungseinheit sowie gegebenenfalls eine Zeitkontrolleinheit zur Überwachung von Meldungsfolgen aufweist.
In vorteilhafter Weise erfolgt die Visualisierung in Windowtechnik und das System umfaßt ein Dialogmaskensystem.
Die Erfindung offenbart ein System zur Ermittlung von auf Straßenstrecken, insbesondere Autobahnen, bezogene Verkehrsinformationen, wobei mittels ortsfester Detektoren lokale Erfassungsquerschnitte gebildet, verkehrsbezogene Meßwerte erfaßt, mittels lokaler Rechner vorverarbeitet und auf ein vorgegebenes Datenprotokoll normiert, aggregiert und per Funk an eine übergeordnete Datenverarbeitungsanlage übertragen werden.
Die Erfindung ermöglicht die Realisierung eines stufenförmig organisierten Erfassungs- und Verarbeitungssystems. Dadurch können unterschiedliche Verkehrsmodelle auf unterschiedliche Stufen angewandt werden, die teils lokal, teil zentral ablaufen. Die Vorteile sind, daß bereits kurzfristig Ergebnisse erzielt werden können, die durch Ausweitung in die einzelnen Stufen konsolidiert und verfeinert werden. Durch die Auflösung in einzelne Teilaufgaben bzw. Stufen ergibt sich ein hohes Maß an Flexibilität und an Ausfallsicherheit durch die Bildung von Rückfallebenen. Durch die lokale Voranalyse des Verkehrs ergeben sich Möglichkeiten zur äußerst energiesparenden, ereignisorientierten Datenübertragung zu den übergeordneten Datenverarbeitungsanlagen bzw. -zentralen.
Mit der Erfindung wird vorgeschlagen, daß ortsfeste Detektoren an Anschlußstellen, Knotenpunkten und dergleichen positioniert werden. Darüber hinaus wird vorgeschlagen, daß die Anordnungsdichte der ortsfesten Detektoren in Abhängigkeit von Verkehrserwartungsschätzungen bestimmt wird. Somit lassen sich durch die Anordnung vieler lokaler Erfassungssysteme flächendeckende Netze aufbauen. Mit der Erfindung ist es auch möglich, einen Gesamtnetzaufbau zu organisieren. An verkehrstechnisch kritischen Positionen werden lokale Detektoren und Vorverarbeitungsrechner angeordnet, die über Funk in vorzugsweise digitaler Technologie die Daten an übergeordnete Datenverarbeitungsanlagen bzw. -zentralen weiterleiten. Dort können dann weitere Verkehrsmodelle auf die Daten angewandt werden.
Aus der lokalen Auswertung ergibt sich die Möglichkeit der lokalen Zustandserkennung. Durch die Verknüpfung der Daten benachbarter lokaler Erfassungsquerschnitte kann ein sogenannter streckenbezogener Level of Service in einer übergeordneten Datenverarbeitungsanlage oder einer dem Gesamtnetz zugeordneten Zentrale ermittelt werden.
Die Verknüpfung dieser Daten, ggf. in Kombination mit den Daten der lokalen Erfassungsquerschnitte ermöglicht die Errechnung einer erweiterten Situationserkennung. Hier können dynamische Zustandsschätzungen erfolgen, um eine verbesserte Zustandsschätzung in kritischen Streckenabschnitten durch Zuschaltung eines angepaßten Systems zur erweiterten Situationserkennung zu erlangen. Die Ergebnisse sind detaillierte streckenbezogene Daten und feiner untergliederte Situationsklassifizierungen. Darüber hinaus lassen sich Angaben einer etwaigen Sicherheit der jeweiligen Schätzung erzielen. Eine Korrektur hinsichtlich stark verrauschter Daten wegen schlechter Datenübertragung, bei größeren Zeitintervallen oder nur sporadischen Daten ist mit der Erfindung vorgesehen.
Mit besonderem Vorteil wird vorgeschlagen, daß zur lokalen Vorverarbeitung der Daten deren Plausibilität anhand von Modellvergleichen überprüft wird, Mittelwertberechnungen durchgeführt, aus der Veränderung der Meßwerte Trendfaktoren ermittelt, und daß aus den ermittelten Daten taktweise Zustandscodes ermittelt werden. Als Meßwerte werden zumindest Fahrzeuggeschwindigkeit, Verkehrsstärke und querschnittsbezogene Belegung erfaßt.
Nachdem von einem Detektor, beispielsweise einem Passiv-Infrarot-Detektor, Meßdaten geliefert werden, werden diese vorverarbeitet, beispielsweise indem Mittelwertberechnungen, Plausibilitätskontrollen und Trendfaktorermittlungen durchgeführt werden. Aus den Veränderungen der Daten oder den Daten selbst werden dann Zustandscodes ermittelt, beispielsweise in der Form eines Zahlenwertes für Zustände wie freier Verkehrsfluß, Staugefahr, Stop and Go, Stau oder Stillstand u.s.w. Auswertungszyklen können beispielsweise alle 1 bis 5 Minuten gewählt werden. Der Auswertungszyklus kann jedoch variabel festgelegt werden, beispielsweise in Abhängigkeit von den Zustandscodes oder den Verkehrszuständen. Das gleiche gilt für die Datenübertragungsrate, die beispielsweise in Abhängigkeit von dem ermittelten Zustandscode angewandt wird, beispielsweise bei freiem Verkehrsfluß alle 30 Minuten eine Übertragung bei Mittelwertbildung alle 5 Minuten. Je nach Störzustand kann die Übertragungsdichte erhöht werden. Dabei werden die Datenübertragungsraten benachbarter Erfassungsquerschnitte aufeinander abgeglichen.
Die Meßwerte können fahrspurenbezogen erfaßt werden, was aber nicht zwingend erforderlich ist, es können auch andere Erfassungsquerschnitte definiert werden. Auch ist es grundsätzlich möglich, Fahrzeugtypunterscheidungswerte, also beispielsweise Lkw, Pkw und dergleichen zu erfassen.
Mit der Erfindung wird vorgeschlagen, daß übergeordnete Datenverarbeitungsanlagen zumindest für zu Gruppen zusammengefaßte benachbarte Erfassungsquerschnitte zugeordnet werden. Als übergeordnete Datenverarbeitungsanlage kann eine Zentrale für alle Erfassungsquerschnitte eines Netzes oder für mehrere übergeordnete Datenverarbeitungsanlagen zugeordnet werden.
Die Netzorganisation kann in beliebigen Stufen erfolgen, was die Flexibilität und die Datensicherheit beeinflußt. Hier können wirtschaftliche Parameter als Randbedingung verwendet werden.
Mit der Erfindung wird weiterhin vorgeschlagen, daß berechnete Datenreihen durch Modellvergleiche mit vorgegebenen Modellen überprüft bzw. korrigiert, daß zentrale Datenauswertungen zur Störfallerkennung durchgeführt und daß zentrale Datenauswertungen zur dynamischen Zustandsschätzung durchgeführt werden.
Darüber hinaus wird weiterhin vorgeschlagen, daß Quelle-Ziel-Beziehungen durch die Analyse der Daten aller Erfassungsquerschnitte eines Netzes ermittelt, daß die Daten zur Routensuche, zur Ausgabe von Verkehrsleitungsinformationen ausgewertet, zur Präzisierung statistischen Analysen unterzogen und daß die Daten zur Abgabe von Verkehrsentwicklungsprognosen ausgewertet werden.
Mit der Erfindung wird ein System bereitgestellt, um unterschiedliche Arten und Qualitäten von Verkehrsinformationsdaten zur Verfügung zu stellen. Hauptaufgabe ist es, solche Daten für die Kraftfahrzeugführer aufzubereiten und diesen zweckmäßige Informationen bereitzustellen. Dabei kann es sich beispielsweise um Reisezeitanzeigen, Routenanzeigen, Verkehrsschlußprognosen, Stauanzeigen und dergleichen handeln. In den einzelnen Fahrzeugen werden beispielsweise Informationsdisplays angeordnet, auf welchen die Kraftfahrzeugführer ihre geplanten Routen und die Reisezeitinformationen angezeigt bekommen. Sie können dann beispielsweise unter verschiedenen Alternativen die jeweils schnellste Route wählen. Zusätzlich oder alternativ können Hinweise auf Stauentwicklungen, Wahrscheinlichkeiten in Bezug auf die weitere Entwicklung auf dem bevorstehenden Streckenabschnitt und dergleichen angezeigt werden. Die Anwendungsbreite ist umfangreich.
Mit der Erfindung wird ein äußerst flexibles System angegeben, mit welchem unter Verknüpfung unterschiedlichster Verkehrsmodelle ein nahezu netzumfassendes, flächendeckendes Verkehrsinformationssystem aufbaubar ist, welches Daten für unterschiedlichste Informationszwecke liefert. Es können herkömmliche und bereits bekannte Modelle und Verfahren eingesetzt und kombiniert werden. Prognosen können ganglinienbasierte Prognosen an Meßstellen, modellgestützte Prognosen für Abschnitte und Maschen und Ergänzungen nicht meßbarer Effekte unter Verwendung künstlicher Intelligenz sein. Für die Berechnung von Mittelwerten werden übliche Formeln eingesetzt.
Das System kann ergänzt werden um Systeme, die tageszeitabhängige Standardzusatzinformationen, beispielsweise tageszeitabhängige und streckenbezogene Reisezeitinformationen, einbringen.
Weitere Vorteile und Merkmale der Erfindung ergeben sich aus der folgenden Beschreibung eines detailliert erläuterten und durch diverse Figuren veranschaulichten Beispiels.
Dabei zeigen
  • Figur 1 den strukturellen Zusammenhang von Anwendungen,
  • Figur 2 schematisch die Kommunikation zwischen den einzelnen Modulen,
  • Figur 3 die Online-Verarbeitung von Meßwerten,
  • Figur 4 die Einspursimulation mit Vollerfassung,
  • Figur 5 ein Struktogramm des Verkehrsmodells Stufe 1,
  • Figur 6 ein Struktogramm des Verkehrsmodells Stufe 2,
  • Figur 7 ein Struktogramm des Verkehrsmodells Stufe 3,
  • Figur 8 ein Struktogramm des Meldungsmanagers,
  • Figur 9 eine schematische Übersicht über das Archiv,
  • Figur 10 ein Struktogramm zur Simulation der Einspurerfassung,
  • Figur 11 ein Struktogramm zur Offline-Simulation,
  • Figur 12 eine Visualisierung der Verkehrsinformationen,
  • Figur 13 ein Symbol für Verkehrsstörungen,
  • Figur 14 eine Landkarte als Hintergrund für die Visualisierung,
  • Figur 15 eine Einstellung der Farbgebung für die Visualisierung in Fenstertechnik
  • Figur 16 eine Übersicht über verkehrstechnische Meldungen in Fenstertechnik und
  • Figur 17 eine Meldung über Störungen in Fenstertechnik.
    • Zum Zweck der Erstellung eines lokalen Verkehrserfassungssystems ist zur Verkehrsdatenerfassung, Verkehrsdatenarchivierung, Verkehrsdatenvisualisierung und Analyse der Verkehrssituation ein zentraler Verkehrsrechner installiert. Für diesen ist ein X25-Anschluß zur Datenübertragung mit einem Modacom-Netzwerk installiert. Über diesen Datenanschluß erhält die Zentrale die Daten der außenliegenden Meßstellen.
    Die Hardware der Zentrale besteht aus einem PC als Kommunikationsrechner für die Schnittstelle zum Modacom-Netz (X25/Modacom) und einer Workstation als Verkehrs- und Visualisierungsrechner. Die vorgenannten Rechnerkomponenten sind in einem LAN miteinander verbunden. Zur Datenübertragung mit den Außenstationen (Verkehrsdetektion) ist ein X25-Anschluß vorgesehen.
    Es werden eine Reihe von Anwendungen softwaretechnisch realisiert, wie sie in Figur 1 dargestellt sind:
  • Basissoftware für rechnerinterne Kommunikation zwischen Applikationen über Warteschlangen
  • Meldungsmanager
  • Basissoftware für Kommunikation, Melde-Log-System wird in Verbindung mit dem Meldungsmanager eingesetzt
  • Verteiler
  • Anwendung zur Verteilung von Datentelegrammen an verschiedene Applikationen.
    • Datentelegramme sind durch Datentyp-Nummern gekennzeichnet, Applikationen durch systemeindeutige Applikations- und Rechnernummern. In der Verteiltabelle ist zu einem Datentyp hinterlegt, an welche Applikationen er gesendet werden soll.
    Datenflußkontrolle
    Die Applikation dient zur Datenflußkontrolle. Sie bekommt über den Verteiler die Datentelegramme, deren Datenfluß zu überwachen ist. In der Parametrierdatei ist hinterlegt, welche Datentypen in welchem Zeitraster überwacht werden sollen. Die Aktionen, die ausgeführt werden (Senden eines Telegramms), wenn der Empfang eines Telegramms z.B. für einen Meßquerschnitt länger als durch das zugehörige Zeitraster spezifiziert ausbleibt, sind in einer weiteren Datei, nach Aktionen für das Meldesystem und der Visualisierung getrennt parametriert, festgelegt. Im allgemeinen wird an das Meldesystem ein Meldetelegramm gesendet, das auf den fehlenden Datentyp für den bestimmten Meßquerschnitt hinweist und angibt, wie lange er schon nicht mehr empfangen wurde.
    Vorteil der Datenflußkontrolle ist gegenüber der Datenflußüberwachung, die bereits durch das Kommunikationsmodul bezüglich der Aggregierungsmodule durchgeführt wird, daß der Weg der Telegramme über den Verteiler und somit das Kommunikationssystem mitüberwacht wird.
    Zeitsynchronisierung
    Die Rechneruhrzeit wird täglich durch einen Funkuhrtreiber und eine an einer seriellen Schnittstelle angeschlossenen Funkuhr synchronisiert.
    Cron
    Der Cron ist die zentrale Stelle des UNIX-Systems zum Anstoß zyklisch auszuführender Anwendungen. Der Zeitpunkt, wann welche Applikation oder UNIX-Stapeldatei ausgeführt werden soll, wird je UNIX-Benutzer in einer eigenen Datei parametriert.
    Meldungskonverter
    Der Meldungskonverter mekonv selektiert aus den vom Meldesystem erzeugten Telegrammen mit Meldungen jene heraus, die eine Aussage über die Erreichbarkeit eines Aggregierungsmoduls machen. Die Meldungen werden in besondere Telegramme konvertiert und an die Visualisierung (über den Verteiler) gesendet, so daß der Zustand in den Detailinformationen über Messquerschnitte und Abschnitte angezeigt werden kann. Jede Meldung wird zyklisch (ca. alle 15 Minuten) wiederholt, so daß nach einem Neustart der Visualisierung nach einiger Zeit aktuelle Zustände angezeigt werden können.
    Begriffe :
  • AM: Aggregierungsmodul. Auswerteeinheit zur Aggregierung der Detektormeßwerte und Abwicklung der Datenübertragung zur Zentrale.
  • AM-ID: Aggregierungsmodul-Identifikationsnummer, systemweit eindeutig Applikations-Ressourcen Programmspezifische Einstellungen, die mit Hilfe von Funktionen des X-Window-Systems ausgewertet werden. Müssen bestimmten Konventionen entsprechen und werden in Applikations-Ressource-Files definiert.
  • BABSY/X: Bundesautobahn System basierend auf UNIX
  • Cadis: Computer aided dispatcher, hier: Server-Rechner für Modacom-Kommunikation
  • DAFL: Datenflusskontrolle
  • Detektor: kleinste physikalische Erfassungseinheit
  • DE / DE-Kanal: Datenendgerät, kleinste logische Erfassungseinheit
  • DT: Datentyp
  • KOMMOD: Kommunikationsmodul Modacom
  • LLI: Logical Link Identifier, Funkmodem-Identifikationsnummer
  • Modacom: Mobil data communication, Funkdienst der DeTeMobil.
  • MQ: Messquerschnitt, Zusammenfassung der Detektoren einer Fahrtrichtung
  • SYM: Synchronzeit Manager
  • SiAM: Siemens Aggregierungsmodul
  • TLS: Technische Lieferbedingungen für Streckenstationen
    • Basissystem
    Das Kommunikationsmodul ist für die Datenübertragung zwischen dem Modacom-Server auf dem Gateway-Rechner und den weiteren Komponenten des Zentralrechners zuständig, wie es in Figur 2 dargestellt ist.
    Der Modacom-Server des Gateway-Rechners wickelt selbständig die Kommunikation mit dem Modacom-Netz über Datex-P/X.25 ab. Er stellt die von den Aggregierungsmodulen empfangenen Daten, um entsprechende Protokollinformationen reduziert, über die TCP/IP-Socket-Schnittstelle dem Kommunikationsmodul zur Verfügung.
    Umgekehrt nimmt er über die gleiche Schnittstelle die vom Kommunikationsmodul zum Senden an die Aggregierungsmodule bereitgestellten Daten entgegen und sorgt für die Einspeisung in das Modacom-Netz.
    Dem Kommunikationsmodul fallen folgende Aufgaben zu :
    an der Schnittstelle zum/vom Modacom-Server
  • Empfangen von Daten der Aggregierungsmodule,
  • Empfangen von Modacom/X.25-spezifischen Nachrichten des Modacom-Servers,
  • Senden von Parametrierungsdaten für die Aggregierungsmodule
    • an der Schnittstelle zum Basissystem
  • Senden von Verkehrsdaten an den Verteiler,
  • Senden von Statusnachrichten an den Verteiler bzw. an den Meldungsmanager,
    • des weiteren
  • Umsetzung von telegrammspezifischen in systeminterne Adressierungselemente,
  • Sammlung aller Verkehrsdaten eines Erfassungszyklusses,
  • Senden der Daten eines Erfassungszyklusses bei Vollständigkeit oder nach Timeout,
  • Telegrammkonvertierungen,
  • von Verkehrsdatentelegramm (Funktionscode 'V')
    • Verkehrsdaten nach Telegramm Datentyp 40 (neu, Ergebnisübergabe SiAM)
    • Datenendgerätestatus nach BABSY/X-Telegramm Datentyp 12 (Fehlerstatusantwort der Fahrstreifen)
  • von Statusdatentelegramm (Funktionscode 'S')
    • für 'Wiederanlauf' : nach BABSY/X Telegramm Datentyp 300 (Fehlerstatusantwort der Streckenstation) und
    • für 'spontane Statusmeldung' : in Meldungstelegramm an Meldungsmanager,
  • Verbindungsüberwachung zu den Aggregierungsmodulen,
  • Versorgung und Überwachung der Parametrierung für Aggregierungsmodule (Quittierung durch AM),
  • Senden von Meldungen bezüglich der Verfügbarkeit von
  • Aggregierungsmodul,
  • Daten-Endgerät,
  • Funk-Uhr des Aggregierungsmoduls,
  • Wiederanlauf-Kennung des Aggregierungsmoduls,
  • Überprüfung der Blockchecksumme,
  • Sammlung aller Verkehrsdaten eines Erfassungszyklusses,
  • Umsetzung von telegrammspezifischen in systeminterne Adressierungselemente.
    • Die Verkehrsdaten werden nach AM-ID, den im Datenblock stehenden Erfassungszeitpunkt und DE einem Erfassungsintervall im internen Datenabbild zugeordnet und abgespeichert. Dabei wird anhand der DE-Nr. auch der zugeordnete Meßquerschnitt ermittelt.
    Senden der Daten eines Erfassungszyklusses bei Vollständigkeit oder nach Timeout
    Es wird zyklisch überprüft, ob von allen Meßquerschnitten für alle Fahrspuren (also DE) Daten für den aktuellen Erfassungszyklus vorliegen. Ist dies gegeben, werden die Daten mehrerer MQ zu dem Datentelegramm DT 40 zusammengesetzt und an den Verteiler gesendet. Ist auch nach Ablauf einer einstellbaren Überwachungszeit der Datenpool des aktuellen Intervalls nicht vollständig, so werden die vorhandenen Daten zusammengefaßt und an den Verteiler verschickt. Fehlende Daten werden durch das Setzen der Daten auf die Werte 0xFF bzw 0xFFFE in dem entsprechenden Byte bzw. Word gekennzeichnet.
    Über die laufende und Ende-Telegramm-Nr. können die empfangenden Applikationen erkennen, ob noch weitere Daten für einen Erfassungszyklus zu erwarten sind.
    Verbindungsüberwachung zu den Aggregierungsmodulen
    Werden nach Ablauf einer paramtrierbaren Zeit (z.B. 11 Minuten) von einem AM keine Daten empfangen, so wird das AM als ausgefallen vermerkt und gemeldet.
    Senden von Meldungen bezüglich der Verfügbarkeit
    Der im Datenblock enthaltene Status des DE wird im internen Abbild mitgeführt. Ergibt sich aufgrund der empfangenen Daten eine Änderung, so wird diese mit einem Telegramm Datentyp Fehlerstatus der Fahrstreifen. Zusätzlich meldet das Kommunikationsmodul den Status stündlich an das Meldesystem zum Abgleich des Meldeabbilds mit dem internen Abbild. Der Status der ASIM-Detektoren, der von diesen an den SiAM gemeldet werden und ebenfalls im Statusbyte enthalten ist, wird vom Kommunikationsmodul für eine Meldung aufbereitet und an den Meldungsmanager gesendet.
    Versorgung und Überwachung der Parametrierung für Aggregierungsmodule
    Nach dem Hochlauf des Kommunikationsmoduls sendet er an jedes AM ein Abfragetelegramm zur Ermittlung der verkehrstechnischen Parameter und Statuskennungen des AM, wenn das erste empfangenen Telegramm eines AMs kein Statustelegramm ist. Die weitere Verarbeitung siehe 'Statusdaten eines AM'.
    Betriebsmeldungen und Nachrichten über die Modacom und TCP/IP-verbindungen werden auf dem Modacom-Server mitgeloggt. An das Kommunikationsmodul werden nur Modacom-spezifische Meldungen über die Ablieferung eines Datenpaketes an ein SiAM-Modem weitergereicht.
    Verkehrsmodell:
    Die empfangenen Verkehrs-Rohdaten werden mit Hilfe verkehrstechnischer Verfahren ausgewertet. Ziel ist die Ermittlung ausgewählter Verkehrskenngrößen.
    Die Auswertung erfolgt in drei getrennten Stufen. Die Stufen unterscheiden sich in der Komplexität der eingesetzten Verfahren und damit in Qualität und Art der errechneten Verkehrskenngrößen.
    Auf dem Online-System werden die erfaßten Verkehrsdaten auf zwei Wegen weiterverarbeitet. Neben der Auswertung der unveränderten Vollspurdaten (in Figur 3 dargestellt) werden die Rohdaten durch ein Modul zur Einspursimulation manipuliert (in Figur 4 dargestellt). Die so erzeugten Simulations-Rohdaten werden dann parallel zu den Online-Daten ausgewertet. Online- und Simulationsbereich der Verkehrsmodelle arbeiten unabhängig voneinander.
    Zur offline-Auswertung von archivierten Daten können auf einem Offline-System archivierte Daten wieder eingelesen und den Verkehrsmodellen zugeführt werden.
    Die in den Figuren 3 und 4 schattiert dargestellten Module werden an anderer Stelle beschrieben.
    Die Eingangswerte aller Stufen sind die Meßwerte der Erfassungsquerschnitte.
    Pro Erfassungsintervall werden folgende Werte empfangen.
    qKfz
    Anzahl der Kfz im Erfassungsintervall
    qPkw
    Anzahl der Pkw Erfassungsintervall
    qLkw
    Anzahl der Lkw Erfassungsintervall
    vPkw
    Mittlere Geschwindigkeit der Pkw
    vLkw
    Mittlere Geschwindigkeit der Lkw
    sv
    Standardabweichung der Geschwindigkeiten
    b
    Belegungsgrad
    fBeleg
    Fehlerkennung für Belegungsermittlung
    fLänge
    Fehlerkennung für Längenermittlung
    Durch die Verkehrsmodelle wird der übermittelte Wert für q
    Figure 00170001
    nicht ausgewertet. Dieser Wert wird durch die Verkehrsmodelle berechnet aus qKfz - qLkw.
    Verkehrsmodell Stufe 1 (in Figur 5 dargestellt)
    Für jedes Erfassungsintervall werden die folgenden Kennwerte ermittelt:
  • Reisezeit im Streckenabschnitt,
  • Reisegeschwindigkeit im Streckenabschnitt,
  • Verkehrsdichte im Streckenabschnitt,
  • Standardabweichung der Geschwindigkeit.
    • Falls in einem Erfassungsintervall die Werte eines MQ fehlen, werden die fehlenden MQ-Werte nicht interpoliert. Das Modell arbeitet dann so, als sei dieser MQ im System nicht vorhanden. Falls der fehlende MQ der einzige in einem Abschnitt ist, wird der Abschnitt folglich als Abschnitt ohne MQ behandelt.
    Verkehrsmodell Stufe 2 (in Figur 6 dargestellt)
    Für jedes Erfassungsintervall werden die folgenden Kennwerte ermittelt:
  • Reisezeit im Streckenabschnitt,
  • Reisegeschwindigkeit im Streckenabschnitt,
  • Verkehrsdichte im Streckenabschnitt,
  • Staukennung aufgrund lokaler Meßwerte,
  • Unruhekennung aufgrund lokaler Meßwerte,
  • Bemessungsverkehrsstärke im Abschnitt,
  • Standardabweichung der Geschwindigkeit.
    • In Knotenpunkten bilden Rampen einen eigenen Streckenabschnitt.
    Falls in einem Erfassungsintervall die Werte eines MQ fehlen, werden die fehlenden MQ-Werte nicht interpoliert. Das Modell arbeitet dann so, als sei dieser MQ im System nicht vorhanden. Falls der fehlende MQ der einzige in einem Abschnitt ist, wird der Abschnitt folglich als Abschnitt ohne MQ behandelt.
    Verkehrsmodell Stufe 3 (in Figur 7 dargestellt) Zur Visualisierung:
  • Reisezeiten im Streckensegment
  • Verkehrsdichte im Streckensegment
  • Reisegeschwindigkeit im Streckensegment
  • Situationserkennung: Erkannte Situation im Streckenabschnitt
    • Zur Archivierung:
  • Reisezeiten im Streckenabschnitt
  • Verkehrsdichte im Streckenabschnitt
  • Reisegeschwindigkeit mit Standardabweichung im Streckenabschnitt
  • Situationserkennung: Situationen und Situationswahrscheinlichkeit im Abschnitt zwischen zwei Meßquerschnitten. Der Abschnitt wird identifiziert durch den stromaufwärts gelegenen MQ.
    • Streckenabschnitt ist die Strecke zwischen zwei Knotenpunkten. Segment" ist ein Teil der Strecke zwischen zwei Meßquerschnitten.
    Im Verkehrsmodell 3 wird eine Erweiterte Situationserkennung ( ESE") eingesetzt. Die Algorithmen in ESE werden nicht verändert. Es erfolgt lediglich eine Anpassung der Schnittstellen auf Ein- und Ausgangsseite.
    Die Ergebnisse von ESE beziehen sich auf Abschnitte, die von Meßquerschnitt zu Meßquerschnitt reichen. Im Modul Sammler" werden diese Größen auf streckenabschnitte übertragen, die sich auf den Bereich zwischen zwei Knotenpunkten beziehen.
    Der in Figur 8 als Struktogramm dargestellte Meldungsmanager ist für die Entgegennahme, Aufbereitung und Weitergabe von Meldungen zuständig, die von Prozessen an das Meldesystem abgesetzt werden. Er dient als zentrale Verwaltungsstelle von Daten, die dem Bediener und Beobachter das korrekte oder inkorrekte Arbeiten des Systems anzeigen.
    Für die meisten Meldungen kann projektiert werden, ob die Meldungen ausgedruckt, archiviert oder visualisiert werden und/oder quittungspflichtig sind. Diese Behandlungen werden über die Meldebehandlungsdatei eingestellt.
    Die auszugebenden Meldungstexte werden durch Meldenummer, Parameter zur Ersetzung von Aktualparametern in ein Grundgerüßt von Meldetexten in der Meldetextdatei definiert.
    Der Meldungsmanager besteht aus den Komponenten Meldungsaufbereitung (MEAU) und Meldungsverteilung (MEVT). Zwischen diesen Applikationen ist das Melde-Log-System MESALOG zwischengeschaltet, daß für die Aufbereitung der Meldetexte zuständig ist. MEAU nimmt die Meldungstelegramme der Applikationen über die SIPAX BW.KOM Schnittstelle entgegen und bereitet die darin enthaltenen Aktualparameter für die Übergane an MESALOG auf.
    MEVT speist die fertigen Meldungstexte zur weiteren Verarbeitung in das System ein.
    Visualisierung
    Die Visualisierung dient zur Online-Darstellung der Ergebnisse der verschiedenen Modelle zur Bestimmung der Reisezeitbänder (Reisegeschwindigkeit im Abschnitt) und Dichten, zur Anzeige von Detailinformationen der Abschnitte und Meßquerschnitte, sowie zur Darstellung von Verkehrs- und Betriebsmeldungen.
    Für das Visualisierungssystem werden bestehende Komponenten des BABSY/X-Standard-Systems eingesetzt und ggf. modifiziert bzw. erweitert.
    Das Laufzeitsystem der Visualisierung besteht aus sechs Prozessen, denen jeweils ein spezieller Aufgabenbereich zugeordnet ist:
  • Komponenten :
  • Datenadapter Input
  • Empfang aller Telegramme an die Visualisierung im externen Format über das SIPAX-Interface
  • Plausibilitätsprüfung
  • Konvertierung der Telegramme je nach Hardwarekonfiguration (z.B. wg. unterschiedlicher Byte-Order) in internes Format
  • Anmerkung: Beim T-Mobil-System laufen alle Prozesse, die Daten an die Vislualisierung senden, auf einem Rechner. Daher sind hier externes und internes Datenformat identisch.
    • Verteilung der Telegramme an Zielapplikationen (hier: PAM, MEM) Graphic user interface
    Aufbereitung und Anzeige der Nettodaten in grafischer Form aufgrund von Aktualisierungstelegrammen und Bedieneranforderungen.
  • Anzeige von Betriebs- und verkehrstechnischen Meldungen Entgegennahme von Bedienerquittungen
  • Meldungshandler
  • Empfang der Betriebs- und verkehrstechnischen Meldungen vom Meldesystem
  • Aufbereitung der Meldungen als Klartext
  • Weitergabe der Meldungen an GUI zur Darstellung
    • Prozeß-Abbild-Manager
  • Erzeugen und initialisieren des Prozeß-Abbilds
  • Empfang der Datentelegramme im internen Format
  • Eintragen der Nettodaten ins Prozeß-Abbild
  • Senden des Aktualisierungsanstoßes an GUI
    • Prozeß-Abbild
    Das Prozeß-Abbild wird beim Start der Visualisierung angelegt und mit den statischen Informationen aus den Runtime-Files versorgt.
    Alle Daten, die im laufenden Betrieb zur Visualisierung gesendet werden, werden vom PAM im Prozeß-Abbild hinterlegt.
    Das Prozeß-Abbild wird in einem Shared-Memory geführt. Alle Prozesse, die aus diesem Pool Informationen und Daten benötigen, müssen diesen Shared-Memory in ihren Adreßraum einbinden.
    Zur Interprozeßkommunikation innerhalb des Visualisierungssystems werden Named-Pipes (FIFO) verwendet:
    Pipe Define Quelle Ziel Beschreibung
    appl_to.dapo Q_APPL_DAPO PBM DAPO Starttelegramm
    appl_to.gui Q_APPL_GUI PAM, MEM GUI Aktualisierung, Meldungen
    appl_to.mem Q_APPL_MEM alle Applikationen MEM interne Visualisierungsmeldungen
    gui_to.pbm Q_GUI_PBM GUI PBM Starttelegramm
    dapi_to.pam Q_DAPI_PAM DAPI PAM Telegramme im internen Format
    Alle Telegramme, die innerhalb des Visualisierungssystems versendet werden, besitzen einen einheitlichen Aufbau:
    Byte-Nr Anzahl Beschreibung
    0 2 Anzahl Folgebytes
    2 2 Auftragskennung
    4 k Nettodaten
    : : :
    l m Nettodaten
    Folgende Auftragskennungen werden verarbeitet.
    Auftragskennung Beschreibung
    VIS_MEM_MELDUNG Aktualisierung Meldezeile/Meldeübersicht
    VIS_MEM_PAUSE quittungspflichtige Meldung anzeigen
    VIS_PAM_AKTU Aktualisierungsanstoß vom PAM
    VIS_PA_RESET Prozeß-Abbild initialisieren
    VIS_START Initialisierung der Visualisierung beendet
    Es werden folgende Eingangstelegramme verarbeitet:
    Daten typ Define Beschreibung
    12 FESTAN_MQ_VD_FS Fehlerstatusantwort der Fahrstreifen
    40 ERGBUE_MQ_VD_TMOB0 Ergebnisübergabe
    400 ML_MLDKLASSE_TEXT (quittungspflichtige) Betriebsmeldung
    401 ML_FEHLER_MLD (quittungspflichtige) Fehlermeldung
    403 ML_UNRUHE_STAU (quittungspflichtige) VT-Meldung
    409 ML_UNRUHE_STAU_SIM (quittungspflichtige) VT-Meldung (f. Simulation)
    805 STM_TMOB1 Reisegeschwindigkeit und Dichte lokal
    806 STM_TMOB2 Reisegeschwindigkeit und Dichte Standard
    807 STM_TMOB1_SIM Reisegeschwindigkeit und Dichte lokal (SIM)
    808 STM_TMOB2:SIM Reisegeschwindigkeit und Dichte Standard (SIM)
    1505 STM_ESE_SEG1 Reisegeschw. Und Dichte ESE
    1508 STM_ESE_ABS3 VT-Situation aus ESE
    1509 STM_ESE_SEG1_SIM Reisegeschw. Und Dichte ESE (SIM)
    15012 STM_ESE_ABS3_SIM VT-Situation aus ESE (SIM)
    Die Eingangstelegramme werden in das interne Datenformat konvertiert und die Nettodaten werden im Prozeß-Abbild objektbezogen abgelegt. Über einen Aktualisierungsanstoß wird der Grafik-Prozeß (GUI) über die neuen Daten informiert. Meldungen werden als Klartext an den GUI weitergereicht.
    Die Eingangsdaten werden in folgender Form visualisiert:
    Fehlerstatusantwort der Fahrstreifen - FESTAN MQ VD FS
    Zugeordneter Streckenabschnitt wird mit der eingestellten Farbe für Fehlerkennung eingefärbt.
    In der Detailinfomaske wird der Fehlerstatus angezeigt.
    Ergebnisübergabe - ERGBUE MQ VD TMOB0
    In der Detailinfo-Dialogmaske werden die Verkehrsrohdaten in alphanumerischer (Tabelle) und grafischer (Verkehrsdatenschreiber) Form angezeigt. Ist die Infomaske beim Empfang neuer Daten aufgeblendet, wird die Anzeige aktualisiert.
    Betriebsmeldung - ML MLDKLASSE TEXT
    Der Meldetext wird in die Meldezeile und die Meldungsübersicht für Betriebsmeldungen eingetragen. Ist die Meldung als quittungspflichtig gekennzeichnet, wird zusätzlich ein Quittungsformular aufgeblendet. Ist die parametrierte Anzahl gleichzeitig geöffneter Meldungsfenster erreicht, so werden neu eintreffende quittungspflichtige Meldungen gepuffert. Erst nach Quittierung einer Meldung wird die nächste Meldung aus dem Puffer angezeigt.
    VT-Meldung - ML UNRUHE STAU
    Der Meldetext wird in die Meldezeile und die Meldungsübersicht für verkehrstechnische Meldungen eingetragen. Ist die Meldung als quittungspflichtig gekennzeichnet, wird zusätzlich ein Quittungsformular aufgeblendet. Ist die parametrierte Anzahl gleichzeitig geöffneter Meldungsfenster erreicht, so werden neu eintreffende quittungspflichtige Meldungen gepuffert. Erst nach Quittierung einer Meldung wird die nächste Meldung aus dem Puffer angezeigt.
    Reisegeschwindigkeit und Dichte lokal - STM TMOB1
    Der zugeordnete Abschnitt in den Übersichtsdarstellungen "Reisegeschwindigkeit lokal" und "Dichte lokal" wird entsprechend den eingestellten Schwellwerten und Farbcodes eingefärbt.
    In der Detailinfomaske werden die Daten in alphanumerischer Form angezeigt. Ist die Infomaske beim Empfang neuer Daten aufgeblendet, wird die Anzeige aktualisiert.
    Reisegeschwindigkeit und Dichte Standard - STM TMOB2
    Der zugeordnete Abschnitt in den Übersichtsdarstellungen "Reisegeschwindigkeit Standard" und "Dichte Standard" wird entsprechend den eingestellten Schwellwerten und Farbcodes eingefärbt.
    In der Detailinfomaske werden die Daten in alphanumerischer Form angezeigt. Ist die Infomaske beim Empfang neuer Daten aufgeblendet, wird die Anzeige aktualisiert.
    Reisegeschwindigkeit und Dichte ESE
    Das zugeordnete Segment in den Übersichtsdarstellungen "Reisegeschwindigkeit ESE" und "Dichte ESE" wird entsprechend den eingestellten Schwellwerten und Farbcodes eingefärbt.
    Archiv
    Das Archiv (eine Übersicht ist in Figur 9 dargestellt) empfängt per Message-Queue Daten- und Meldungstelegramme und schreibt diese in Archivdateien, die im sog. Archiv-Bereich" der Festplatte liegen. Nach einem Tageswechsel wird per cron ein Sicherungsmechanismus aktiviert, der die Daten des Vortages komprimiert. Die im komprimierten Daten können auf DAT-Tape gesichert werden. Der Anstoß eines Backups erfolgt manuell durch den Operator.
    Die in Figur 9 schattiert dargestellten Module sind nicht Gegenstand dieser Beschreibung.
    Die nachfolgend genannten Datenarten werden vom Archiv bearbeitet. Die Ergebnisse der Einspursimulation werden unter eigenen Datentypen versendet. Das Archiv unterscheidet anhand des Datentyps, in welchem Archivbereich ein Datensatz zu archivieren ist.
    Datentyp ERGBUE_MQ_VD_TMOB0 Meßwerte der Detektoren
    qKfz
    Anzahl der Kfz im Erfassungsintervall
    qPkw
    Anzahl der Pkw Erfassungsintervall
    qLkw
    Anzahl der Lkw Erfassungsintervall
    vPkw
    Mittlere Geschwindigkeit der Pkw
    vLkw
    Mittlere Geschwindigkeit der Lkw
    sv
    Standardabweichung der Geschwindigkeiten
    b
    Belegungsgrad
    fBeleg
    Fehlerkennung für Belegungsermittlung
    fLänge
    Fehlerkennung für Längenermittlung
    • Datentyp STM_TMOB1 / STM_TMOB1_SIM
    • Reisezeit im Streckenabschnitt
    • Reisegeschwindigkeit im Streckenabschnitt
    • Verkehrsdichte im Streckenabschnitt
    • Datentyp STM_TMOB2 / STM_TMOB2_SIM
    • Reisezeit im Streckenabschnitt
    • Reisegeschwindigkeit im Streckenabschnitt
    • Verkehrsdichte im Streckenabschnitt
    • Stau im Streckenabschnitt
    • Unruhe im Streckenabschnitt
    • Bemessungsverkehrsstärke im Abschnitt
    • Datentyp STM_ESE_ABS1 / STM_ESE_ABS1_SIM
    • Reisezeit im Streckenabschnitt
    • Reisegeschwindigkeit im Streckenabschnitt
    • Verkehrsdichte im Streckenabschnitt
    • Datentyp STM_ESE_ABS2 / STM_ESE_ABS2_SIM
    • Verkehrssituationen mit Wahrscheinlichkeiten im Streckenabschnitt
    • Datentyp ML_UNRUHE_STAU_IN / ML_UNRUHE_STAU_IN_SIM
    • Klartextmeldungen über Unruhe-/Stauerkennung und ESE-Situationserkennung
    • Datentyp ML_FEHLER_MLD_INPUT
    • Klartextmeldung über den Betriebsablauf der Anlage (Detektorstörungen, Übertragungsstörungen, etc.)
    Die Archivierung erfolgt grundsätzlich in ASCII-Dateien. Die Verzeichnisstruktur ist wie folgt aufgebaut:
  • Für die Online-Daten:
  • ./〈ARCHIV-Wurzel〉/〈Datentyp〉/〈Datum〉/〈Identifikation〉
  • Für die Simulations-Daten:
  • ./〈ARCHIV-Wurzel〉/SIM/〈Datentyp〉/〈Datum〉/〈Identifikation〉
    • Für folgende Datentypen werden Verzeichnisse angelegt:
  • Rohdaten: vd40
  • Ergebnisse Stufe 1: vd_st1
  • Ergebnisse Stufe 2: vd_st2
  • Erg. Stufe 3 - Störungen: vd_st3s
  • Erg. Stufe 3 - Verkehrsdaten: vd_st3d
    Meldungen:
    mld
    Dateiname
    ./ARCHIV/vd40/〈datum〉/〈id〉
    z. B:
    ./ARCHIV/19970129/23 = Rohwerte vom 29.01.97
  • für MQ 23
  • Pro MQ wird eine eigene Datei angelegt.
    • Dateiname
    ./ARCHIV/vd_st1/〈datum〉/〈id〉
    z. B:
    ./ARCHIV/vd_st1/19970129/23
    = Ergebnisse VT-Stufe 1 vom 29.01.97 für MQ 23
    Pro MQ und Tag wird eine eigene Datei angelegt.
    Dateiname
    ./ARCHIV/vd_st2//〈datum〉/〈id〉
    analog VT1
    Dateiname
    ./ARCHIV/vd_st3s//〈datum〉/〈id〉
    analog VT1 Dateiname ./ARCHIV/vd_st3d//〈datum〉/〈id〉
    analog VT1
    Betriebsmeldungen
    Dateiname
    ./ARCHIV/mld/〈datum〉/std
    z. B:
    ./ARCHIV/mld/19970129/std = Betr.-Meldungen vom 29.01.97
    Verkehrstechnische Meldungen
    Dateiname
    ./ARCHIV/mld//〈datum〉/vt
    z. B:
    ./ARCHIV/mld/19970129/vt = VT-Meldungen vom 29.01.97
    Im Rahmen der Tagessicherung werden alle im Archivbereich angelegten Dateien komprimiert.
    Die Einspurerfassung von Verkehrsdaten wird durch Einspeisen von manipulierten Rohdaten simuliert (siehe Figur 10). Dazu wird je MQ aus den erfaßten Daten ein Fahrstreifen selektiert, aus dessen Daten die Verkehrsdaten des Gesamtquerschnitts hochgerechnet werden. Der so ermittelte Datensatz wird an die Verkehrsmodelle verteilt und dort bearbeitet. Die Bearbeitung der hochgerechneten Daten in den Verkehrsmodellen unterscheidet sich nicht von der Bearbeitung von Online-Daten.
    Folgende Simulationsparameter sind einstellbar:
  • Je MQ: Zu verwendender Fahrstreifen
  • Werte zur Hochrechnung der Vollspurdaten
    • Auf einem Offline-Rechner können archivierte Daten eingelesen und den Verkehrsmodellen wieder zugeführt werden (siehe Figur 11). Dabei unterscheidet sich die Verarbeitung in den Verkehrsmodellen nicht von der Verarbeitung im online-Fall.
    Der zu simulierende Zeitbereich wird über ein Modul zur Ablaufsteuerung ausgewählt. Die Bedienung der Offlinesimulation wird auf Shell-Ebene gesteuert.
    Die Gestaltung der Bedienoberflächen :
    Ein X-Window System ist ein grafisches standardisiertes Fenstersystem und damit ein internationaler Defacto-Standard für UNIX-Systeme. Es ist ein rechner- und betriebssystemunabhängiges Window-System mit grafischer Benutzeroberfläche, die das gleichzeitige Arbeiten mit mehreren Prozessen ermöglicht. Es ist farbgrafikfähig, arbeitet objektorientiert und mausunterstützt.
    Durch das verwendete Client/Server Konzept können Anwendungen auf anderen UNIX-Rechnern ausgeführt werden, während die Datenein- und ausgabe für diese Prozesse am lokalen Arbeitsplatz erfolgt. Die Benutzer kommunizieren über Fenster mit dem Betriebssystem und den Anwendungen.
    Die Oberfläche teilt sich in eine Menüleiste, zwei Interaktionsbereiche und eine Meldezeile auf. Über die Menüleiste kann der Bediener die einzelnen grafischen Darstellungen anwählen, Detailinformationen abrufen, Meldungen anzeigen etc. In einem Interaktionsbereich werden die Ergebnisse jeweils eines Verfahrens grafisch dargestellt. In der Meldezeile wird die letzte eingehende verkehrstechnische- oder Betriebsmeldung angezeigt.
    Die Darstellung in einem Interaktionsbereich erfolgt in Form einer schematischen Übersicht in Figur 12 über das Autobahnnetz im Raum Köln/Bonn. Dabei sind die Autobahnen im Bereich des Testgebiets in Abschnitte unterteilt, die aufgrund der eingehenden Daten stufenweise eingefärbt werden.
    Zur besseren Orientierung kann in den Hintergrund der Interaktionsbereiche eine Landkarte eingeblendet werden (Menüpunkt Grafik → Karte ).
    In den Interaktionsbereichen werden die Ergebnisse der verschiedenen Modelle zur Bestimmung der Reisezeitbänder (Reisegeschwindigkeit im Abschnitt) und Dichten online darge
    stellt. Die Darstellung kann dabei auf Daten der Vollspurerfassung oder der Einspursimulation basieren. Die Anzeige von Simulationsdaten wird durch die Einfärbung der Überschrift des entsprechenden Interaktionsbereichs gekennzeichnet.
    Im einzelnen sind folgende Darstellungen anwählbar:
    Stufe 1
    • Reisegeschwindigkeitsbänder im Abschnitt aufgrund lokaler Verkehrsdaten (Original)
    • Streckenbezogene Dichte im Abschnitt aufgrund lokaler Verkehrsdaten (Original)
    • Reisegeschwindigkeitsbänder im Abschnitt aufgrund lokaler Verkehrsdaten (Simulation)
    • Streckenbezogene Dichte im Abschnitt aufgrund lokaler Verkehrsdaten (Simulation)
    Stufe 2
    • Reisegeschwindigkeitsbänder im Abschnitt aufgrund von Standardverfahren (Original)
    • Streckehbezogene Dichte im Abschnitt aufgrund von Standardverfahren (Original)
    • Reisegeschwindigkeitsbänder im Abschnitt aufgrund von Standardverfahren (Simulation)
    • Streckenbezogene Dichte im Abschnitt aufgrund von Standardverfahren (Simulation)
    Stufe 3
    • Reisegeschwindigkeitsbänder im Segment aufgrund von wissenschaftlichen Verfahren (Original)
    • Streckenbezogene Dichte im Segment aufgrund von wissenschaftlichen Verfahren (Original)
    • Reisegeschwindigkeitsbänder im Segment aufgrund von wissenschaftlichen Verfahren (Simulation)
    • Streckenbezogene Dichte im Segment aufgrund von wissenschaftlichen Verfahren (Simulation)
    Die Darstellung der Ergebnisse erfolgt dabei durch stufenweise Einfärbung der Streckenabschnitte bzw. Segmente. Hierbei werden folgende Schwellwerte als Voreinstellung verwendet.
    Stufe Farbcode Dichte [Fz/Km] Geschwindigkeit [Km/h]
    Keine Daten hellblau --- ---
    Stufe 1 grün ≤ 20 > 120
    Stufe 2 gelb ≤ 40 > 100
    Stufe 3 orange ≤ 60 > 80
    Stufe 4 rot ≤ 80 > 40
    Stufe 4 magenta > 80 ≤ 40
    Fehler schwarz --- ---
    Über den Menüpunkt Grafik → Legende... können die aktuell eingestellten Schwellwerte angezeigt werden. Schwellwerte und Farbcodes werden im Applikations-Ressource-File definiert.
    In die nachfolgende Tabelle können geänderte Farbcodes und Schwellwerte eingetragen werden.
    Stufe Farbcode Dichte [Fz/Km] Geschwindigkeit [Km/h]
    Keine Daten --- ---
    Stufe 1 ≤ >
    Stufe 2 ≤ >
    Stufe 3 ≤ >
    Stufe 4 ≤ >
    Stufe 4 > ≤
    Fehler --- ---
    In die Übersichtsgrafiken werden an den entsprechenden Stellen Symbole zur Anzeige von Verkehrsstörungen eingeblendet. In den Symbolen wird eine Unruhe-/Staukennung (aus Stufe 2) und eine Situationsnummer (aus Stufe 3) angezeigt.
    Dabei werden Symbole für Verkehrsstörungen, die aufgrund von Daten aus der Vollspurerfassung resultieren, nur in den Grafiken für die Originaldaten angezeigt. Symbole für Störungen aufgrund von Simulationsdaten werden in den Grafiken für die Online-Simulation eingeblendet. Somit ist ein direkter Vergleich möglich.
    Die Symbole sind wie in Figur 13 dargestellt aufgebaut:
    Aus Stufe drei können sechs verschiedene Verkehrssituationen gemeldet werden. Diesen sind die folgenden Situationsnummern zugeordnet:
    Situationsnummer Beschreibung
    0 keine Verkehrsstörung erkannt
    1 verkehrstechnischer Engpaß
    2 baulicher Engpaß
    3 Verdichtung
    4 einwandernder Stau
    5 zugestauter Abschnitt
    6 stockender Verkehr
    Durch Klicken mit der linken Maustaste ohne gleichzeitige Betätigung einer Modifier-Taste (SHIFT, CTRL oder ALT bzw. Ext. Char) an einen beliebigen Punkt innerhalb der Grafik, wird dieser Punkt zum neuen Mittelpunkt.
    Die Definition eines Ausschnitts erfolgt durch das sog. "Rubberbanding". Dabei wird mit Hilfe der Maus ein Rechteck um den gewünschten Bildausschnitt aufgezogen. Der definierte Ausschnitt wird anschließend vergrößert dargestellt.
    Dazu bewegt man den Mauszeiger an die linke obere Ecke des zu vergrößernden Ausschnitts. Mit gedrückter linker Maustaste bewegt man jetzt den Mauszeiger solange, bis das nun sichtbare Rechteck den zu vergrößernden Bereich umschließt. Nach Los-lassen der Maustaste wird der angewählte Ausschnitt vergrößert auf dem Bildschirm dargestellt.
    Durch Betätigen der mittleren Maustaste erscheint an der aktuellen Position des Mauszeigers ein Pop-Up-Menü auf dem Bildschirm. Mit den oberen drei Menüpunkten "größer", "kleiner" und "reset" läßt sich die Darstellung vergrößern, verkleinern bzw. in die Grunddarstellung zurückversetzen. Der Vergrößerungs- bzw. Verkleinerungsfaktor ist der in der Maske Grafik / Layout eingestellte Zoomfaktor.
    Zum Vergrößern oder Verkleinern bewegt man den Mauszeiger an die Stelle im Bild, die zum neuen Mittelpunkt der vergrößerten bzw. verkleinerten Darstellung werden soll. Anschließend betätigt man einmal die mittlere Maustaste. Es erscheint ein Pop-Up-Menü, aus dem die gewünschte Aktion ausgewählt werden kann.
    Für die sensitiven Objekte in den Übersichtsdarstellungen können durch Selektion mit der linken oder rechten Maustaste jeweils in Verbindung mit einer Modifier-Taste (SHIFT oder CTRL) Zusatzinformationen abgerufen werden. Eine Kurzinfo zum Objekt erhält man durch Anklicken mit der rechten Maustaste ohne Betätigung eines Modifiers.
    Sensitive Objekte sind:
    • Abschnitte (Stufe 1 und 2)
    • Segmente (Stufe 3)
    • ortsbezogene Symbole für Verkehrsstörungen
    • Anschlußstellen
    Zur besseren Orientierung kann in den Hintergrund der Interaktionsbereiche eine Landkarte, wie in Figur 14 dargestellt, eingeblendet werden.
    Die Ergebnisse der verschiedenen Modelle zur Bestimmung der Reisegeschwindigkeiten und Dichten werden durch Einfärbung der entsprechenden Streckenabschnitte visualisiert. Dabei werden die Eingangsdaten anhand von Schwellwerten in Stufen eingeteilt.
    Nach Auswahl dieses Menüpunkts wird eine in Figur 15 dargestellt Maske aufgeblendet, in der die aktuell eingestellten Farbcodes und Schwellwerte angezeigt werden.
    Die Farbcodes und Schwellwerte können über eine Ressource-Einstellung geändert werden.
    Das Menü Meldungen enthält folgende Unterpunkte:
    • VT-Meldungen, zur Anzeige der in Figur 16 dargestellten Dialogmaske Verkehrstechnische Meldungen
    • Betriebsmeldungen, zur Anzeige der Dialogmaske Betriebsmeldungen
    Beispiele für verkehrstechnische Meldungen:
  • 09.04.1997-16:23:00 K S2:Stau:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:24:00 G S2:Stau:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:25:00 S2:Unruhe:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:26:00 K S3:VT-Engpass:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:27:00 K S3:Verdichtung:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:28:00 K S3:Bau-Engpass:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:29:00 K S3:Einw. Stau:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:30:00 K S3:Zugest. Abs.:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:31:00 K S3:Stockung:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:32:00 G S3:VT-Engpass:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:33:00 G S3:Verdichtung:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:34:00 G S3:Bau-Engpass:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:35:00 G S3:Einw. Stau:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:36:00 G S3:Zugest. Abs.:A3:AS Lohmar->AS Siegburg/Hennef
  • 09.04.1997-16:37:00 G S3:Stockung:A3:AS Lohmar->AS Siegburg/Hennef
    • Betriebsmeldungen sind Meldungen über erkannte Gerätestörungen, d.h. Störungen der Außenanlage oder über interne Systemfehler.
    Wichtige Meldungen werden dem Operator in einem in Figur 17 dargestellten Message-Dialog zur Quittierung vorgelegt.
    Diese Meldungen müssen durch Aktivierung des Buttons OK bestätigt werden.

    Claims (24)

    1. System zur Ermittlung von auf Straßenstrecken, insbesondere Autobahnen, bezogene Verkehrsinformationen, mit jeweils wenigstens einer Erfassungseinheit, einer Eingangsdatenkommunikationseinheit, einer Datenverarbeitungseinheit zur Erzeugung von Meldesätzen, einer Meldungsmanagementeinheit zur Aufbereitung von Meldesätzen, einer Ausgangsdatenkommunikationseinheit zur Informationsversendung an Verteiler sowie einer Visualisierungseinheit zur Informationsdarstellung.
    2. System nach Anspruch 1, dadurch gekennzeichnet, daß dieses ein Archiv für erfaßte und/oder verarbeitete Informationen aufweist.
    3. System nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses wenigstens eine Anlagenüberwachungseinheit aufweist.
    4. System nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses eine Datenflussüberwachungseinheit aufweist.
    5. System nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses eine Datenverarbeitungsüberwachungseinheit aufweist.
    6. System nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses eine Zeitkontrolleinheit zur Überwachung von Meldungsfolgen aufweist.
    7. System nach wenigstens einem der vorhergehenden Ansprüche, wobei mittels ortsfester Detektoren lokale Erfassungsquerschnitte gebildet, verkehrsbezogene Meßwerte erfaßt, mittels lokaler Rechner vorverarbeitet und auf ein vorgegebenes Datenprotokoll normiert, aggregiert und per drahtloser Übermittlung an eine übergeordnete Datenverarbeitungsanlage übertragbar sind.
    8. System nach Anspruch 7, dadurch gekennzeichnet, daß ortsfeste Detektoren an Anschlußstellen, Knotenpunkten und dergleichen positioniert sind.
    9. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Anordnungsdichte der ortsfesten Detektoren in Abhängigkeit von Verkehrserwartungsschätzungen bestimmt ist.
    10. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß zur lokalen Vorverarbeitung der Daten deren Plausibilität anhand von Modellvergleichen überprüfbar ist.
    11. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß aus der Veränderung der Meßwerte Trendfaktoren ermittelbar sind.
    12. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß aus den ermittelten Daten taktweise Zustandscodes ermittelbar sind.
    13. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Meßwerte fahrspurenbezogen erfaßbar sind.
    14. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß übergeordnete Datenverarbeitungsanlagen zumindest für zu Gruppen zusammengefaßte benachbarte Erfassungsquerschnitte zugeordnet sind.
    15. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß als übergeordnete Datenverarbeitungsanlage eine Zentrale für alle Erfassungsquerschnitte eines Netzes oder für mehrere übergeordnete Datenverarbeitungsanlagen zugeordnet ist.
    16. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß in wenigstens einer übergeordneten Datenverarbeitungsanlage streckenbezogene Verkehrsinformationen durch Verknüpfung der übertragenen Daten benachbarter Erfassungsquerschnitte errechenbar sind.
    17. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß zentrale Datenauswertungen zur Störfallerkennung durchführbar ist.
    18. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Daten zur Routensuche auswertbar sind.
    19. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Daten zur Ausgabe von Verkehrsleitungsinformationen auswertbar sind.
    20. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Daten zur Abgabe von Verkehrsentwicklungsprognosen auswertbar sind.
    21. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Daten zur Ausgabe von Reisezeitinformationen auswertbar sind.
    22. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Daten zur Ausgabe von Stauinformationen auswertbar sind.
    23. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Visualisierung in Windowtechnik erfolgt.
    24. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses ein Dialogmaskensystem umfaßt.
    EP98118423A 1997-10-06 1998-09-29 System zur Ermittlung von Verkehrsinformationen Expired - Lifetime EP0915445B1 (de)

    Priority Applications (1)

    Application Number Priority Date Filing Date Title
    DK98118423T DK0915445T3 (da) 1997-10-06 1998-09-29 System til fremskaffelse af trafikinformationer

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    DE19744033 1997-10-06
    DE19744033 1997-10-06

    Publications (3)

    Publication Number Publication Date
    EP0915445A2 true EP0915445A2 (de) 1999-05-12
    EP0915445A3 EP0915445A3 (de) 2000-08-02
    EP0915445B1 EP0915445B1 (de) 2005-06-29

    Family

    ID=7844692

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP98118423A Expired - Lifetime EP0915445B1 (de) 1997-10-06 1998-09-29 System zur Ermittlung von Verkehrsinformationen

    Country Status (6)

    Country Link
    EP (1) EP0915445B1 (de)
    AT (1) ATE298914T1 (de)
    DE (1) DE59812892D1 (de)
    DK (1) DK0915445T3 (de)
    ES (1) ES2244026T3 (de)
    PT (1) PT915445E (de)

    Cited By (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1154389A1 (de) * 2000-05-10 2001-11-14 DaimlerChrysler AG Verfahren zur Verkehrslagebestimmung für ein Verkehrsnetz

    Citations (5)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US4311876A (en) * 1977-04-06 1982-01-19 Nissan Motor Company, Ltd. Route guidance system for roadway vehicles
    US5131020A (en) * 1989-12-29 1992-07-14 Smartroutes Systems Limited Partnership Method of and system for providing continually updated traffic or other information to telephonically and other communications-linked customers
    WO1994011839A1 (en) * 1992-11-19 1994-05-26 Kjell Olsson Prediction method of traffic parameters
    US5317311A (en) * 1988-11-14 1994-05-31 Martell David K Traffic congestion monitoring system
    US5539645A (en) * 1993-11-19 1996-07-23 Philips Electronics North America Corporation Traffic monitoring system with reduced communications requirements

    Patent Citations (5)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US4311876A (en) * 1977-04-06 1982-01-19 Nissan Motor Company, Ltd. Route guidance system for roadway vehicles
    US5317311A (en) * 1988-11-14 1994-05-31 Martell David K Traffic congestion monitoring system
    US5131020A (en) * 1989-12-29 1992-07-14 Smartroutes Systems Limited Partnership Method of and system for providing continually updated traffic or other information to telephonically and other communications-linked customers
    WO1994011839A1 (en) * 1992-11-19 1994-05-26 Kjell Olsson Prediction method of traffic parameters
    US5539645A (en) * 1993-11-19 1996-07-23 Philips Electronics North America Corporation Traffic monitoring system with reduced communications requirements

    Cited By (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    EP1154389A1 (de) * 2000-05-10 2001-11-14 DaimlerChrysler AG Verfahren zur Verkehrslagebestimmung für ein Verkehrsnetz

    Also Published As

    Publication number Publication date
    ES2244026T3 (es) 2005-12-01
    EP0915445A3 (de) 2000-08-02
    DE59812892D1 (de) 2005-08-04
    EP0915445B1 (de) 2005-06-29
    ATE298914T1 (de) 2005-07-15
    PT915445E (pt) 2005-11-30
    DK0915445T3 (da) 2005-10-17

    Similar Documents

    Publication Publication Date Title
    DE10049504B4 (de) Verfahren und System zur tranparenten Unterstützung von entfernten Eingabe-/Ausgabeeinrichtungen in einem Prozeßsteuersystem
    DE69914080T2 (de) Funktionsblocksvorrichtung zur datenanzeige in einem prozessteuerungssystem
    EP3688742B1 (de) System zur erzeugung und/oder aktualisierung eines digitalen modells einer digitalen karte
    DE69533349T2 (de) Persistenzspezifizierungssystem und Verfahren für Hochleistungssubkarten auf Anfrage
    EP1096348A1 (de) Integration eines Feldleitgerätes in ein Anlagenleitsystem
    WO2003067815A1 (de) Nachrichtenanalyseeinrichtung und verfahren zum anzeigen von nachrichten
    DE10392438T5 (de) Vorrichtung und Verfahren zur zentralen Überwachung und Steuerung von Anlagen
    DE4221841C2 (de) Überwachungs-Kontrollsystem zur Überwachung mehrerer überwachter Geräte
    EP0192120B2 (de) Verfahren und Einrichtung zur Datenübertragung in der Fernwirktechnik
    DE102005037913A1 (de) Verfahren zur wiedergabeorientierten Fehlerdokumentaion
    DE4029290C2 (de)
    DE2048240A1 (de) Einrichtung und Verfahren zum Erfas sen und Identifizieren von Daten aus men reren Signalquellen
    EP1286497B1 (de) Verfahren zur visuellen Darstellung von Zuständen von Netzelementen eines zu überwachenden Netzwerks, sowie eine Überwachungseinrichtung und ein Programmmodul hierfür
    DE69433313T2 (de) Multi-Master Überwachungssystem
    EP0915445B1 (de) System zur Ermittlung von Verkehrsinformationen
    DE3718472A1 (de) Verfahren und system zur verarbeitung von nachrichten
    AT410491B (de) Kommunikationsverfahren zur realisierung von ereigniskanälen in einem zeitgesteuerten kommunikationssystem
    EP0970869B1 (de) Verfahren zur sicheren Anzeige des Zustandes einer signaltechnischen Anlage
    DE2423195A1 (de) Wartungsvorrichtung
    DE2264085C2 (de) Fernwirkanlage mit wenigstens einer Hauptzentrale, der ein Hauptnetz zugeordnet ist
    EP0902405A2 (de) Verfahren zur Ermittlung von Verkehrsinformationen
    DE3136586C2 (de)
    EP0106985B1 (de) Betriebsüberwachung von digitalen Übertragungsstrecken
    EP0902403B1 (de) Verfahren zur Ermittlung von Verkehrsinformationen
    EP1636960B1 (de) Automatisierungssystem mit vereinfachter diagnose und fehlerbehebung

    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: A2

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    AX Request for extension of the european patent

    Free format text: AL;LT;LV;MK;RO;SI

    PUAL Search report despatched

    Free format text: ORIGINAL CODE: 0009013

    AK Designated contracting states

    Kind code of ref document: A3

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    AX Request for extension of the european patent

    Free format text: AL;LT;LV;MK;RO;SI

    RIC1 Information provided on ipc code assigned before grant

    Free format text: 7G 08G 1/01 A, 7G 08G 1/127 B

    17P Request for examination filed

    Effective date: 20010201

    AKX Designation fees paid

    Free format text: AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    17Q First examination report despatched

    Effective date: 20020808

    GRAP Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOSNIGR1

    GRAS Grant fee paid

    Free format text: ORIGINAL CODE: EPIDOSNIGR3

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

    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 Corresponds to:

    Ref document number: 59812892

    Country of ref document: DE

    Date of ref document: 20050804

    Kind code of ref document: P

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: FG4D

    Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

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

    Ref country code: IE

    Payment date: 20050811

    Year of fee payment: 8

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: NV

    Representative=s name: SIEMENS SCHWEIZ AG

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

    Ref country code: CY

    Payment date: 20050901

    Year of fee payment: 8

    GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

    Effective date: 20050815

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

    Ref country code: PT

    Payment date: 20050923

    Year of fee payment: 8

    REG Reference to a national code

    Ref country code: DK

    Ref legal event code: T3

    REG Reference to a national code

    Ref country code: SE

    Ref legal event code: TRGR

    REG Reference to a national code

    Ref country code: GR

    Ref legal event code: EP

    Ref document number: 20050402923

    Country of ref document: GR

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FG2A

    Ref document number: 2244026

    Country of ref document: ES

    Kind code of ref document: T3

    PLBI Opposition filed

    Free format text: ORIGINAL CODE: 0009260

    ET Fr: translation filed
    26 Opposition filed

    Opponent name: DEUTSCHE TELEKOM AG

    Effective date: 20060322

    PLAX Notice of opposition and request to file observation + time limit sent

    Free format text: ORIGINAL CODE: EPIDOSNOBS2

    NLR1 Nl: opposition has been filed with the epo

    Opponent name: DEUTSCHE TELEKOM AG

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

    Ref country code: MC

    Payment date: 20060823

    Year of fee payment: 9

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

    Ref country code: DK

    Payment date: 20060913

    Year of fee payment: 9

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

    Ref country code: GR

    Payment date: 20060914

    Year of fee payment: 9

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

    Ref country code: LU

    Payment date: 20060918

    Year of fee payment: 9

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

    Ref country code: BE

    Payment date: 20060919

    Year of fee payment: 9

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

    Ref country code: IE

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

    Effective date: 20060929

    Ref country code: CY

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

    Effective date: 20060929

    PLAF Information modified related to communication of a notice of opposition and request to file observations + time limit

    Free format text: ORIGINAL CODE: EPIDOSCOBS2

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

    Ref country code: ES

    Payment date: 20061024

    Year of fee payment: 9

    PLBB Reply of patent proprietor to notice(s) of opposition received

    Free format text: ORIGINAL CODE: EPIDOSNOBS3

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

    Ref country code: PT

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

    Effective date: 20070329

    REG Reference to a national code

    Ref country code: PT

    Ref legal event code: MM4A

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

    Effective date: 20070329

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: MM4A

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

    Ref country code: FI

    Payment date: 20070808

    Year of fee payment: 10

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

    Ref country code: SE

    Payment date: 20070906

    Year of fee payment: 10

    Ref country code: IT

    Payment date: 20070926

    Year of fee payment: 10

    BERE Be: lapsed

    Owner name: *SIEMENS A.G.

    Effective date: 20070930

    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 NON-PAYMENT OF DUE FEES

    Effective date: 20070930

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

    Ref country code: FR

    Payment date: 20070918

    Year of fee payment: 10

    REG Reference to a national code

    Ref country code: DK

    Ref legal event code: EBP

    PLAB Opposition data, opponent's data or that of the opponent's representative modified

    Free format text: ORIGINAL CODE: 0009299OPPO

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

    Ref country code: BE

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

    Effective date: 20070930

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

    Ref country code: DK

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

    Effective date: 20071001

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FD2A

    Effective date: 20071001

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

    Ref country code: ES

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

    Effective date: 20071001

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PCAR

    Free format text: SIEMENS SCHWEIZ AG;INTELLECTUAL PROPERTY FREILAGERSTRASSE 40;8047 ZUERICH (CH)

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

    Ref country code: GR

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

    Effective date: 20080402

    Ref country code: FI

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

    Effective date: 20080929

    REG Reference to a national code

    Ref country code: FR

    Ref legal event code: ST

    Effective date: 20090529

    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: 20070929

    Ref country code: IT

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

    Effective date: 20080929

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

    Ref country code: FR

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

    Effective date: 20080930

    PLCK Communication despatched that opposition was rejected

    Free format text: ORIGINAL CODE: EPIDOSNREJ1

    PLBN Opposition rejected

    Free format text: ORIGINAL CODE: 0009273

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

    Free format text: STATUS: OPPOSITION REJECTED

    27O Opposition rejected

    Effective date: 20091218

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

    Ref country code: SE

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

    Effective date: 20080930

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

    Ref country code: GB

    Payment date: 20100916

    Year of fee payment: 13

    GBPC Gb: european patent ceased through non-payment of renewal fee

    Effective date: 20110929

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

    Ref country code: GB

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

    Effective date: 20110929

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

    Ref country code: NL

    Payment date: 20140904

    Year of fee payment: 17

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

    Ref country code: CH

    Payment date: 20141204

    Year of fee payment: 17

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

    Ref country code: AT

    Payment date: 20150806

    Year of fee payment: 18

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

    Ref country code: DE

    Payment date: 20151120

    Year of fee payment: 18

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

    REG Reference to a national code

    Ref country code: NL

    Ref legal event code: MM

    Effective date: 20151001

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

    Ref country code: CH

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

    Effective date: 20150930

    Ref country code: LI

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

    Effective date: 20150930

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

    Ref country code: NL

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

    Effective date: 20151001

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R119

    Ref document number: 59812892

    Country of ref document: DE

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MM01

    Ref document number: 298914

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20160929

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

    Ref country code: DE

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

    Effective date: 20170401

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

    Ref country code: AT

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

    Effective date: 20160929