WO2006062483A1 - Procede et systeme de gestion intelligente d'incident de circulation - Google Patents

Procede et systeme de gestion intelligente d'incident de circulation Download PDF

Info

Publication number
WO2006062483A1
WO2006062483A1 PCT/SG2004/000398 SG2004000398W WO2006062483A1 WO 2006062483 A1 WO2006062483 A1 WO 2006062483A1 SG 2004000398 W SG2004000398 W SG 2004000398W WO 2006062483 A1 WO2006062483 A1 WO 2006062483A1
Authority
WO
WIPO (PCT)
Prior art keywords
incident
traffic
incident management
case
management plan
Prior art date
Application number
PCT/SG2004/000398
Other languages
English (en)
Inventor
Xin Jin
Kim Siah Ang
Sim Ho Wee
Feng Xie
Siew Keong Chan
Shao Jun Wang
Dong Yun Wang
Yong Wei Xu
Original Assignee
St Electronics (Info-Comm Systems) Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by St Electronics (Info-Comm Systems) Pte. Ltd. filed Critical St Electronics (Info-Comm Systems) Pte. Ltd.
Priority to PCT/SG2004/000398 priority Critical patent/WO2006062483A1/fr
Priority to CN200480044863.3A priority patent/CN101111862B/zh
Publication of WO2006062483A1 publication Critical patent/WO2006062483A1/fr

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles
    • G08G1/205—Indicating the location of the monitored vehicles as destination, e.g. accidents, stolen, rental

Definitions

  • Traffic management systems are used in many areas to detect and respond to changing traffic conditions.
  • One of the key areas in such a traffic management system is efficient incident management, which aids in reducing delays caused hy traffic incidents and improves the efficiency of the transportation network.
  • Efficient management of traffic incidents may include the prompt removal of incident vehicles and other debris.
  • Incident management is a complex process involving many tasks, such as the timely collection of incident information, knowledge of the position and availability of emergency response units, communication with relevant personnel (e.g., police, environmental departments, or a state park authority) for coordination, provision of timely advice to motorists through variable message signs, and adjustment of traffic signal timing to alleviate traffic congestion. Decisions regarding these tasks may vary depending on an incident's nature, location, blockage, and the congestion impact to the surrounding roadways and traffic flow. Because of the complexity and variability of the tasks and the corresponding incident scenarios, current traffic management systems lack the ability to adequately handle the decision making process.
  • Fig. 1 is a diagram of one embodiment of a traffic management system that includes an intelligent traffic incident management engine.
  • Fig. 2 is a diagram of one embodiment of an architecture for the intelligent traffic incident management engine of Fig. 1.
  • Fig. 3 is a flowchart of one embodiment of a method for an incident management plan automation process that may be executed within the system of Fig. 1.
  • Fig. 4 is one embodiment of a data flow that may be used to implement at least some portions of the method of Fig. 3 within the system of Fig. 1.
  • Fig. 5 is a flow chart of one embodiment of a case based reasoning (CBR) process that may be used with the data flow of Fig. 4.
  • CBR case based reasoning
  • Fig. 6 is a flow chart of one embodiment of a similarity matching process that may be used with the CBR process of Fig 5.
  • Fig. 7 is a flow chart of one embodiment of a ruled based reasoning process that may be used with the data flow of Fig. 4.
  • Fig. 8 is a flow chart of one embodiment of a traffic incident management plan validation process that may be used with the data flow of Fig. 4.
  • the present disclosure relates to traffic incident management and, more particularly, to an automated decision support system that can accommodate various incident scenarios.
  • the following disclosure provides many different embodiments or examples. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting.
  • the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.
  • a traffic management system 100 includes several components that may be used for detecting and responding to traffic incidents.
  • the system 100 includes front-end equipment control unit 102, front-end data collection unit 104, and incident detection/confirmation unit 106.
  • the front-end data collection unit 104 may be similar to that disclosed in Australian Patent No. 1089300, entitled “IMAGE PROCESSING TECHNIQUES FOR A VIDEO BASED TRAFFIC MONITORING SYSTEM AND METHODS THEREFOR,” and hereby incorporated by reference in its entirety.
  • the incident detection/confirmation unit 106 may be similar to that disclosed in U.S. Patent No. 6,470,261, entitled “AUTOMATIC FREEWAY-INCIDENT DETECTION SYSTEM AND METHOD USING ARTIFICIAL NEURAL NETWORK AND GENETIC ALGORITHMS,” and hereby incorporated by reference in its entirety.
  • the front-end equipment control unit 102, front-end data collection unit 104, and incident detection/confirmation unit 106 feed data into one or more central data processing servers 108, which in turn is coupled to an intelligent traffic incident management engine (iTIME) 110.
  • iTIME intelligent traffic incident management engine
  • the iTIME 110 processes the input incident and produces one or more traffic control plans that assist in alleviating the impact of the input traffic incident.
  • information is sent to the front-end equipment control unit 102 via a traffic control gateway 112 for execution of the traffic control plan.
  • the system 100 enables the deployment of a process for automated decision support to incident management in advanced traffic management centers.
  • the system 100 automates the generation of real-time incident management plans from captured input data and supports incident validation, plan solving and validation, and plan evaluation and knowledgebase updates.
  • the iTIME 110 uses a hybrid intelligent engine that utilizes a heuristics approachbased on real-time incident data and proposes incident management plans. Based on modeled incident characteristics, plans may be solved using either case based reasoning (CBR) or rule based reasoning (RBR) processes.
  • CBR case based reasoning
  • RBR rule based reasoning
  • the CBR process is generally used to handle incident scenarios that are specific in nature and location, which make it difficult to define generic handling logics.
  • the RBR process is generally used to handle incident scenarios that are of a generic nature and location.
  • the combined implementation of these two processes provides greater coverage of incident scenarios than a pure RJBR system, while maintaining faster processing capabilities than a pure CBR system.
  • a discriminate index is created and used for process identification by the hybrid engine (e.g., whether to use the CBR or RBR process), which is also able to handle automatic incident management plan updates based on real-time input incident progress.
  • the system 100 enables an incident management plan for a given incident to be infer entially developed based on experiences stored in abstract incident cases when the CBR process is applied.
  • the inference process implemented with the CBR process is an incident management domain-specific CBR model. More specifically, a traffic incident is represented as a case and an incident management plan is represented as a solution.
  • the CBR inference process conducts incident case similarity matching, case retrieval, incident management plan adaptation, and case based learning.
  • the similarity matching supports feature sets represented in string, character, integer, float, Boolean, and date/time formats that are found in incident cases.
  • the plan adaptation provides two methods, one using a lightweight rule set and the other using case references, to change a retrieved plan to suit a given input incident.
  • the case learning process supports case based updates when a new abstract incident is identified after a produced plan has been accepted via human interaction.
  • the incident management plan may be developed based on a set of heuristic rules when the RBR process is applied.
  • the inference process implemented with the RBR process applies a generic rule firing process with one or more comprehensive rule sets tailored for incident management.
  • the rule firing process uses heuristics based on incident characteristics, traffic equipment status, and traffic flow conditions, and deploys a recursive process to check for plan updates.
  • the present disclosure provides a solution that automates some or all of the decision support process for traffic incident management.
  • the automated process provides a means for traffic management centers to operate more efficiently in their incident management tasks.
  • the present disclosure may employ a hybrid expert system engine that applies a combination of CBR and RBR techniques to improve the decision response performance of a pure CBR or RBR system by providing a higher scenario response rate and a lower response time.
  • a CBR processor tailored for the domain of traffic incident management may be implemented to bypass the difficulty of structural differences in business logic that may be encountered in many traffic incident management scenarios faced by different traffic management centers.
  • the architecture includes an internal communication server 202 coupling a central data processor 204 with a hybrid incident management engine (IME) 206.
  • the IME 206 is also coupled to a CBR processor 208, a RBR processor 210, and a shared knowledgebase storage 212.
  • the communication server 202 acquires traffic incidents and updates related to a particular incident, and sends out incident management plans. There is no limit to the number of traffic incidents or number of updates of an incident that can be processed by IME 206, other than technical constraints that may be imposed by hardware and/or software.
  • the IME 206 may filter received (input) incidents, convert the input incident data format into a standardized data format, select an adequate expert system process from the CBR processor 208 and RBR processor 210 for plan solving based on a defined discriminate index, validate a plan, and transform the plan into an output format that supports traffic equipment control protocols.
  • the CBR processor 208 and RBR processor 210 are components that implement the corresponding inference processes, as will be described later in greater detail.
  • the shared knowledgebase storage 212 provides means for storing and retrieving case base, rule base, and facts data. More specifically, the shared knowledgebase storage 212 (and associated processes) provides means to store and retrieve cases and rules, as well as facts data.
  • the facts data is designed and implemented to build and trace the relationship between one or more incident impact zones and integrated expressway/arterial incident management zone/means through a number of storage units. It is understood that each of the illustrated architecture components may be combined, separated into additional components, or otherwise distributed. For example, although illustrated as a single database, the shared knowledgebase storage 212 may actually be multiple databases. In addition, the CBR processor 208 and RBR processor 210 may be integrated with the ME 206.
  • a method 300 illustrates one embodiment of an incident management plan automation process that may be executed, for example, within the system 100 of Fig. 1. Many of the steps of the method 300 will be described in greater detail later.
  • incident information may be received or updated (if the corresponding incident was previously entered). Such incident information may be received from, for example, the incident detection/confirmation unit 106 of Fig. 1.
  • the incident is validated, with only valid incidents being passed on.
  • hx step 306 a plan is formulated based on the incident information and, in step 308, the formulated plan is itself validated against real-time traffic equipment information before being processed for priority and formatted for output based on one or more traffic equipment control protocols.
  • step 310 the plan is displayed for review and acceptance (e.g., by a user). Once accepted, the plan is sent for execution in step 312 (e.g., to the front-end equipment control unit 300 via the traffic control gateway 112 of Fig. 1).
  • the plan may be evaluated and used to update the knowledgebase storage 212 (Fig. 2) as follows.
  • this evaluation requires that the plan activation results be returned back to the iTIME processor 110 (Fig. 1). More specifically, the plan's execution is updated in iTIME, along with the amount of user intervention that occurred prior to acceptance.
  • a plan confidence index is calculated and the values are stored for knowledgebase learning.
  • the plan confidence index is defined as a weighted sum of the amount of positive/negative human intervention with the plan in terms of acceptance, modification, or rejection of the plan elements.
  • the plan confidence index is an indicator of tlie knowledge level represented in the knowledgebase storage 212, performance of the inference process, and any change of incident management business logics.
  • plan confidence index is stored for future analysis in step 316 along with any incident/plan case based updates in step 318.
  • the progress of an incident may be monitored and captured in step 302 and repeatedly handled by steps 304-314 as described in real-time automated mode and updates are needed.
  • incident information is retrieved by the communication server 202 (Fig. 2).
  • the incident information may be in a standardized input data format, such as that illustrated below in Table 1. If the information is not already standardized, the communication server 202 or another component (e.g., the IME 206) may convert the input information into the standardized format.
  • the input incident data captures incident characteristics represented by time, location, nature, damage, congestion length, lane blockage, etc.
  • These inputs can be obtained via a variety of means, including closed circuit television or wireless surveillance devices, SOS phones (e.g., help or emergency phones placed along roads with a button for calling a traffic control center) or cell phones, video/loop detectors' automatic incident detection outputs, probe or patrol vehicles, radio communications with emergency service units, traffic police, or civil defense groups, at various levels of detail.
  • the incident information undergoes a feature validation process by the IME 206 (Fig. 2).
  • This feature validation process aids in eliminating possibilities that may lead an inference process to enter a state where no solution exists or a state of deadlock due to insufficient input or conflicting inputs.
  • the feature validation process may use existing business intelligence, including validation of manageable traffic incident types and validation of incident temporal and spatial information according to logical incident development sequences.
  • the IME 206 executes a process using a discriminate index to determine whether to apply the CBR or RBR process for developing a plan for the given input incident.
  • the discriminate index which may be initialized prior to step 406, is a collection of selected incident features (e.g., a reduced set of dimensions in its defined feature space) that best represents the incident with respect to the incident case base.
  • the selection of particular features is based on the analysis of all the incident features in relation to the plan generation process, so long as the selected features represent discriminate factors in a given problem domain. These particular features are compared to the existing incidents in the incident case base and, in the present example, a successful match is defined as an exact match of string operations. If a successful match occurs (e.g., if the given incident passes the discriminate index), the CBR process will be selected. If not, the RBR process will be selected. hi step 408, a determination is made as to whether the selected process is a CBR process. If so, the CBR processor 208 is used to develop the plan in step 410. If not (e.g., if the RBR process is selected), the RBR processor 210 is used in step 412.
  • step 410 is executed if the CBR process is selected.
  • CBR is a technique that generates a solution to a given problem by making one or more inferences and adapting the inference(s) to past experiences.
  • the present disclosure implements the CBR process in an incident management domain-specific CBR model. More specifically, a traffic incident is represented as a case and an incident management plan is represented as a solution.
  • the set of values of an incident feature defines the domain of a corresponding attribute of a case.
  • Past experiences are represented by a collection of incident case/plan sets and may be referred to as a case base of a collection of abstract cases.
  • An abstract case is an incident prototype that includes information about a representative group of incident scenarios.
  • the case based reasoning process makes inferences for incident management plan generation in four steps as illustrated in Fig. 5, including the steps of similarity matching, case retrieval, case adaptation, and case learning.
  • the engine first loads a current case configuration during the start process. After adding an incident (step 502) and modeling it into the current configuration of case features, a similarity matching process is executed in step 504 to identify the most relevant case (e.g., the winning case) as the starting point for developing the plan.
  • a method incorporating a process such as the Nearest-Neighborhood Matching Algorithm (see, e.g., Case-Based Reasoning, Janet Kolodner, Morgan Kaufinann Publishers, Inc, 1993, which is hereby incorporated by reference) may be used for this purpose.
  • case features are configurable and only currently configured features are used in similarity matching.
  • the process uses a similarity matrix to store the similarity value between a new input case and a list of indexed cases and, in step 602, selects one or more cases.
  • the process computes a similarity value between the input case and one of the indexed cases using a numerical instance, with the similarity defined as the closeness in terms of numerical distance,
  • SM k similarity value of the k th case instance
  • f. normalized value of feature i of given case
  • f. normalized value of feature i of k th abstract case instance
  • w. value of the imp ortance of feature i
  • n number of features.
  • step 606 a determination is made as to whether any of the cases identified as similar pass a predefined acceptance threshold (e.g., whether there is a winning case).
  • a winning case is identified as the case that evidences the highest similarity value for an acceptable neighborhood.
  • step 610 a determination is made as to whether the accepted case is unique. More specifically, when the input case resides in more than one neighborhood and has equal similarity values for those neighborhoods, the winning case will be selected in step 612 based on its historical activation frequency (e.g., a case that is activated more frequently will be selected over a case that is not activated as frequently). hi step 614, the winning case(s) may be marked for retrieval. It is noted that step 504 (Fig. 5) differs from step 406 (Fig. 4) in both search space and search methods. The combination of these two approaches reduces the search space and increases the similarity speed while maintaining the case reference coverage. Returning to Fig. 5, in step 506, the winning case (e.g., the incident/plan pair that belongs to the winning case) that was identified in step 504 is loaded. It can be implemented on any indexed case base.
  • the winning case e.g., the incident/plan pair that belongs to the winning case
  • changes may be made to the solution of the retrieved case (e.g., changes may be made to the incident management plan of the retrieved abstract incident case to suit the current input incident).
  • changes may be made to the incident management plan of the retrieved abstract incident case to suit the current input incident.
  • only a partial plan may be changed based on its associated business logic.
  • the first method makes use of a rule firing process.
  • a set of rules is defined for case adaptation that work on incident attributes such as incident type. For example, an equipment control value for a variable message sign in the plan may be checked and changed based on the current input incident type if it appears in the message produced by the case retrieval.
  • a simple logical process may be used to replace the event type on one or more of the display equipment pieces in the plan.
  • This method may be implemented using a rule engine with a light-weight set of rules.
  • the second method works within the case process by looking for the field with the least similarity between the input case and the winning case, and replacing the field using the relevant partial solution.
  • a constraint to this method is that the selected field for adaptation must be independent of other fields.
  • an incident type field of "accident” is generally independent of other incident attributes.
  • a variable message sign showing "accident” in a winning case can be replaced with the message "road work" to correspond to the current input case.
  • the process identifies the feature having the lowest similarity value in the incident management plan and retrieves the most likely partial solution from a case having the highest similarity value for that particular feature. The combination results in the correct field for the input case.
  • the first method provides a more precise process for case adaptation, but requires at least a partial understanding of the process logic in order to define the rule set.
  • the second method requires less understanding of the process logic, but depends on the amount and type of knowledge that exists in the abstract cases of the case base. hi step 510, the plan (with any adaptations from step 508) is produced.
  • step 412 is executed if the RBR process is selected.
  • the condition part of a rule is placed on the left side of the rule equation and may include one or more patterns. It is used to match the current data against rule execution.
  • the action part of a rule is placed on the right side of the rule equation and is used to change the result of rule execution.
  • a condition is defined as the input incident pattern or facts data, while an action is defined as a derived fact data or an element in an incident management plan.
  • the RBR process generally involves context initialization and updates, rule set identification and retrieval, rule firing, and recursive condition checking.
  • context initialization and updates occur when the input incident is added to the RBR processor 210.
  • rule packets are identified and loaded.
  • the rule packets provide an organizational structure for rule sets, with rule sets being organized in different packets (e.g., based on incident location) to improve the performance of the rule firing process.
  • the relevant rules are then fired in step 706 according to incident and facts data activation.
  • the rule firing process includes incident pattern matching and fires all the rules that satisfy the given condition(s) until there are no more rules to be fired.
  • step 708 a list of plan elements is formed based on the fired rules and added to the database.
  • a determination is made in step 710 as to whether a recursive condition exists and, if so, traffic data is updated in step 712 and the process returns to step 706.
  • a recursive condition exists and, if so, traffic data is updated in step 712 and the process returns to step 706.
  • One example where such recursion may be used involves one or more signal control parameters that need to be dynamically adjusted to correspond to prevailing traffic conditions at every data update interval.
  • the recursive condition enables these adjustments to occur.
  • the RBR process of Fig. 7 is implemented using an application program interface (API) such as those provided by ILOG Corporation of Gentilly, France, which may be configured to work with comprehensive rule sets built for incident management.
  • API application program interface
  • step 414 the data flow 400 continues to step 414, where the resulting plan is validated.
  • an action type is checked in step 802 to ensure that only currently valid command types are consolidated before being sent.
  • An action is one type of traffic management command defined in the system 100 and implemented by the iTIME 110.
  • step 804 identifies any obsolete commands that were implemented in the previous incident state and that need to be removed from the current state.
  • Step 806 proposes suitable commands for use in restoring the equipment to pre-incident control states.
  • Step 808 automates the command implementation sequence according to such factors as priority and time delay.
  • Process 810 converts all commands to the appropriate subsystem command protocol.
  • step 416 a determination is made as to whether the plan is valid (based on step 414). If it is not valid, an error code is sent in step 418 and the data flow 400 ends. It is understood that additional steps may be taken at this time. For example, a default plan may be implemented prior to ending, and the error code may indicate that the default plan has been proposed. If the plan is valid, the plan is sent for review and output for execution in steps 420 and 422, respectively. The plan output is implemented in a standardized data format, such as that illustrated below in Tables 2a and 2b. Table 2a illustrates an incident management plan, while Table 2b represents one of the multiple ITS control commands or incident management actions of Table 2a.
  • the output data format maps the various incident response/management means into a standard incident management plan that includes an array of traffic management command structures, represented by system identification, command type code, command parameter values, and command delays.
  • the traffic management system and command type can be compatible with any commercial traffic management system able to communicate with external interfaces, or any human based management means able to receive radio signals, facsimiles, pages, cellphone calls, web accessible, or wireless information. Examples of such control types are listed below in Table 3.

Abstract

L'invention concerne un procédé et un système destinés à générer automatiquement un plan de gestion d'incident de circulation. Conformément à un exemple, le procédé comprend la réception d'une information représentant un incident de circulation, et la validation d'au moins une portion de l'information reçue, en vue de s'assurer que l'information reçue est suffisante pour permettre la génération du plan de gestion d'incident de circulation. Le procédé comprend l'utilisation d'un moteur d'intelligence hybride utilisant un processus de raisonnement par cas (CBR) ou un processus de raisonnement par règles (RBR) pour générer le plan de gestion d'incident de circulation, par utilisation d'un indice de discrimination correspondant aux caractéristiques de l'incident. Le procédé est associé à un processus de post-génération de validation de plan. Le procédé inclut un mécanisme d'évaluation de plan au moyen d'un indice de confiance.
PCT/SG2004/000398 2004-12-06 2004-12-06 Procede et systeme de gestion intelligente d'incident de circulation WO2006062483A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/SG2004/000398 WO2006062483A1 (fr) 2004-12-06 2004-12-06 Procede et systeme de gestion intelligente d'incident de circulation
CN200480044863.3A CN101111862B (zh) 2004-12-06 2004-12-06 用于智能交通事故管理的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2004/000398 WO2006062483A1 (fr) 2004-12-06 2004-12-06 Procede et systeme de gestion intelligente d'incident de circulation

Publications (1)

Publication Number Publication Date
WO2006062483A1 true WO2006062483A1 (fr) 2006-06-15

Family

ID=36578195

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2004/000398 WO2006062483A1 (fr) 2004-12-06 2004-12-06 Procede et systeme de gestion intelligente d'incident de circulation

Country Status (1)

Country Link
WO (1) WO2006062483A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105761491A (zh) * 2016-04-26 2016-07-13 安徽大学 交通事故侦测与预警系统
CN107862166A (zh) * 2017-12-12 2018-03-30 哈尔滨工业大学 一种智能的仿真实验设计系统及设计方法
CN110276400A (zh) * 2019-06-24 2019-09-24 重庆大学 一种基于ahp-灰色关联分析算法的刀夹具优选方法
CN110390138A (zh) * 2019-06-24 2019-10-29 重庆大学 一种刀夹具的多目标综合优选方法
CN111415064A (zh) * 2020-02-21 2020-07-14 神华和利时信息技术有限公司 预案流程获得方法、系统、存储介质及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884212A (en) * 1994-04-15 1999-03-16 Thomson-Csf Process for monitoring traffic for automatic vehicle incident detection
WO2000007113A1 (fr) * 1998-07-31 2000-02-10 Cet Technologies Pte Ltd. Systeme automatique de detection d'incidents sur autoroute utilisant des reseaux neuronaux artificiels et des algorithmes genetiques
WO2001069569A2 (fr) * 2000-03-15 2001-09-20 Raytheon Company Systeme automatique predictif de detection d'accident utilisant une identification automatique de vehicules

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884212A (en) * 1994-04-15 1999-03-16 Thomson-Csf Process for monitoring traffic for automatic vehicle incident detection
WO2000007113A1 (fr) * 1998-07-31 2000-02-10 Cet Technologies Pte Ltd. Systeme automatique de detection d'incidents sur autoroute utilisant des reseaux neuronaux artificiels et des algorithmes genetiques
WO2001069569A2 (fr) * 2000-03-15 2001-09-20 Raytheon Company Systeme automatique predictif de detection d'accident utilisant une identification automatique de vehicules

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105761491A (zh) * 2016-04-26 2016-07-13 安徽大学 交通事故侦测与预警系统
CN107862166A (zh) * 2017-12-12 2018-03-30 哈尔滨工业大学 一种智能的仿真实验设计系统及设计方法
CN107862166B (zh) * 2017-12-12 2020-12-11 哈尔滨工业大学 一种智能的仿真实验设计系统及设计方法
CN110276400A (zh) * 2019-06-24 2019-09-24 重庆大学 一种基于ahp-灰色关联分析算法的刀夹具优选方法
CN110390138A (zh) * 2019-06-24 2019-10-29 重庆大学 一种刀夹具的多目标综合优选方法
CN111415064A (zh) * 2020-02-21 2020-07-14 神华和利时信息技术有限公司 预案流程获得方法、系统、存储介质及电子设备

Similar Documents

Publication Publication Date Title
CN110209835B (zh) 一种异常检测方法及装置、计算机存储介质及电子设备
CN111475804A (zh) 一种告警预测方法及系统
CN109299642A (zh) 基于人像识别的逻辑布控预警系统及方法
CN112163446B (zh) 一种障碍物检测方法、装置、电子设备及存储介质
CN108900353A (zh) 故障告警方法及终端设备
CN111176953B (zh) 一种异常检测及其模型训练方法、计算机设备和存储介质
Motamed Developing a real-time freeway incident detection model using machine learning techniques
CN106254137A (zh) 监管系统的告警根源分析系统及方法
KR20190143832A (ko) 항공 교통 관리 전자 시스템 테스트 방법, 해당 전자 장치 및 플랫폼
CN112633262B (zh) 通道监测方法、装置、电子设备及介质
CN112257546B (zh) 一种事件预警方法、装置、电子设备及存储介质
WO2006062483A1 (fr) Procede et systeme de gestion intelligente d'incident de circulation
CN117421433A (zh) 一种图文智能舆情分析方法及系统
CN101111862B (zh) 用于智能交通事故管理的方法和系统
KR20200086423A (ko) 모바일 기기와 인공지능 영상 분류기를 이용한 제보 방법 및 그 시스템
Das et al. Trustworthy situation assessment via belief networks
CN115146878A (zh) 指挥调度方法、系统、车载设备及计算机可读存储介质
CN104346246B (zh) 故障预测方法和装置
KR20210027326A (ko) 모바일 기기와 인공지능 영상 분류기를 이용한 제보 방법 및 그 시스템
Bu et al. Support Vector Machine for Classification of Terrorist Attacks Based on Intelligent Tuned Harmony Search.
Rafanelli et al. Neural-logic multi-agent system for flood event detection
CN112434901A (zh) 无人机交通巡逻方案的智能重决策方法和系统
KR102341467B1 (ko) 인공지능 기반 대피우선순위를 설정하는 알고리즘을 이용하여 재난상황에서 우선권이 있는 운전자부터 순차적으로 알람을 전송함으로써 차량의 막힘이 없이 신속한 대피가 가능한 주차장 재난대피시스템의 운영방법
CN117456726A (zh) 基于人工智能算法模型的异常停车识别方法
CN114091625B (zh) 一种基于故障代码序列的车辆零件失效预测方法及系统

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 200480044863.3

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 04801750

Country of ref document: EP

Kind code of ref document: A1