Construction method of high-speed early warning system, electronic device and storage medium

Abstract

The application relates to the technical field of intelligent transportation system modeling, and discloses a construction method of a high-speed early warning system, an electronic device and a storage medium, which are characterized in that a demand model, a function architecture model, a logic architecture model and a physical architecture model are constructed, and a model file is output and simulated and tested based on data flow, control flow, interaction timing and parameter constraint relationships among the models, so that the technical problem that interface definition, data flow and timing constraint among a vehicle, a road and a cloud lack executable formalized description, resulting in low system collaboration and integration difficulty, is solved; the architecture scheme of the high-speed early warning system can be simulated and verified in the model design stage; the simulation test result can be compared with the constraint relationship defined in the constraint model graph; architecture defects can be found and corrected in the early system development stage; the system collaboration and integration efficiency are improved; and the later repair cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation system modeling technology, specifically to a method for constructing a high-speed early warning system, electronic equipment, and storage medium. Background Technology

[0002] Vehicle-road-cloud integration refers to the fusion of the physical and information spaces of people, vehicles, roads, and the cloud into a unified cyber-physical system. Based on collaborative perception, decision-making, and control, it aims to achieve safe, energy-efficient, comfortable, and highly efficient operation of intelligent connected vehicle transportation systems. Road-cloud integrated systems are characterized by high coupling among multiple disciplines, specialties, and entities, encompassing multiple subsystems such as vehicle-side, roadside, cloud platform, and communication networks. Their architectural design faces challenges such as real-time fusion of multi-source heterogeneous data and issues related to system reliability and verifiability.

[0003] In related technologies, the architecture design of collaborative early warning systems based on vehicle-road-cloud integration mainly follows traditional systems engineering methods, which rely on document-based structured decomposition and natural language description. However, as a complex large-scale system encompassing vehicles, roads, cloud, and network, the collaborative early warning system based on vehicle-road-cloud integration is characterized by high complexity, high overall investment, and significant social impact. In traditional document-based design methods, the design results of each design stage are fragmented, and the interface definitions, data flows, and timing constraints between vehicles, roads, and cloud lack executable formal descriptions, resulting in low collaboration and integration difficulties. Summary of the Invention

[0004] This invention provides a method for constructing a high-speed early warning system, an electronic device, and a storage medium to solve the problem that in the traditional design method of a collaborative early warning system architecture based on vehicle-road-cloud integration, the interfaces, data flows, and timing constraints between vehicles, roads, and the cloud lack executable formal descriptions, resulting in low system coordination and integration difficulties.

[0005] In a first aspect, the present invention provides a method for constructing a high-speed early warning system, the method comprising: Obtain the system requirements of the high-speed early warning system to be constructed, generate at least one requirement model diagram based on the system requirements, construct a requirement model based on the requirement model diagram, and the high-speed early warning system includes at least one subsystem; Based on the system requirements, the top-level functions of the high-speed early warning system are decomposed to obtain at least one behavioral model diagram. Based on the behavioral model diagram, the interaction sequence between each subsystem is defined to obtain a functional architecture model. Based on the interaction sequence defined in the behavior model diagram, the data flow and control flow between each subsystem are extracted, and at least one structural model diagram is generated according to the data flow and control flow. Based on the structural model diagram, the interconnection architecture between each subsystem is defined to obtain the logical architecture model. Based on the functional requirements of each subsystem in the interconnection architecture, the parameters that need to be configured in each subsystem are determined, and at least one constraint model diagram is generated. Based on the constraint model diagram, the constraint relationship between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model. The requirement model, the functional architecture model, the logical architecture model, and the physical architecture model are output as model files. The model files are then subjected to simulation tests. The simulation test results are compared with the constraint relationships defined in the constraint model diagram. If the comparison passes, the architecture scheme of the high-speed early warning system is output.

[0006] This invention addresses the technical problem of low system cohesion and integration difficulties caused by the lack of executable formal descriptions of interface definitions, data flow, and timing constraints between vehicles, roads, and the cloud. It solves this problem by constructing a requirement model, functional architecture model, logical architecture model, and physical architecture model, and by outputting model files and conducting simulation tests based on the data flow, control flow, interaction timing, and parameter constraint relationships between each model. The invention allows for simulation verification of the high-speed early warning system architecture during the model design phase, enabling comparison of simulation test results with the constraint relationships defined in the constraint model diagram. This allows for the discovery and correction of architectural defects in the early stages of system development, improving system cohesion and integration efficiency, and reducing later repair costs.

[0007] In one optional implementation, the requirement model diagram includes a requirement analysis diagram and a use case diagram. The step of generating at least one requirement model diagram based on the system requirements and constructing a requirement model based on the requirement model diagram includes: Extract the requirement information from the system requirements, and divide the requirement information into a top-level capability set and a sub-capability set corresponding to each top-level capability set according to a preset requirement dimension; A requirement analysis diagram is generated based on the hierarchical relationship between the various requirement information, and a use case diagram is generated based on the correlation between the various requirement information. The requirement model is then constructed based on the requirement analysis diagram and the use case diagram.

[0008] This invention, through extracting requirement information from system requirements, divides the requirement information into a top-level capability set and corresponding sub-capability sets according to preset requirement dimensions, and generates a requirement analysis diagram based on the hierarchical relationship between each requirement information and a use case diagram based on the correlation between each requirement information. This technical solution, which constructs a requirement model based on the requirement analysis diagram and use case diagram, solves the technical problems of unclear requirement information classification, difficulty in visually expressing hierarchical relationships and correlations, leading to misunderstandings and low communication efficiency in traditional documented requirement analysis. It achieves structured classification, hierarchical display, and correlation confirmation of requirement information, improving the accuracy and traceability of requirement analysis.

[0009] In one optional implementation, the step of decomposing the top-level functions of the high-speed early warning system according to the system requirements to obtain at least one behavioral model diagram includes: Based on the system requirements, the high-speed early warning system is decomposed layer by layer from the overall system to the subsystem, from the subsystem to the functional module, and from the functional module to the sub-function, to obtain at least one system function of the high-speed early warning system; Logical elements are determined according to the business process of the high-speed early warning system, and at least one behavioral model diagram is generated based on the system functions, the logical elements, and the execution order between the system functions.

[0010] This invention addresses the technical problems of inconsistent granularity, difficulty in clearly expressing the execution order and logical relationships between functions, and inconsistencies in understanding system behavior caused by traditional functional decomposition. It achieves top-down structured decomposition of system functions and visualized modeling of functional execution processes, providing a clear behavioral basis for defining the interaction sequence between subsequent subsystems. This approach, based on system requirements, decomposes the high-speed early warning system layer by layer, from the overall system to subsystems, from subsystems to functional modules, and from functional modules to sub-functions.

[0011] In one optional implementation, the behavioral model diagram includes an activity diagram and a sequence diagram. The step of defining the interaction sequence between subsystems based on the behavioral model diagram to obtain a functional architecture model includes: Based on the activity diagram, the execution flow of each functional module of the high-speed early warning system to be constructed under the preset early warning scenario is determined, and the execution flow includes data flow and control flow; The interaction sequence between each subsystem is defined based on the sequence diagram, and the functional architecture model is obtained according to the execution flow and the interaction sequence. The interaction sequence includes message format, triggering conditions and timeout handling mechanism.

[0012] This invention provides a technical solution for determining the execution flow of each functional module of a high-speed early warning system under a preset early warning scenario based on an activity diagram. This execution flow includes data flow and control flow. Furthermore, it defines the interaction sequence between each subsystem based on a sequence diagram, including message format, triggering conditions, and timeout handling mechanisms. This solution, based on the execution flow and interaction sequence, yields a functional architecture model. It addresses the technical problems of unclear functional execution flows and lack of standardized descriptions of interaction sequences among vehicle, road, and cloud subsystems, leading to low system synergy. It achieves unified modeling of the functional module execution flow and subsystem interaction sequence, providing a complete interaction specification for defining the interconnect architecture in the logical architecture.

[0013] In one optional implementation, the structural model diagram includes a module definition diagram and an internal module diagram, and the interconnection architecture includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between the subsystems. The logical architecture model is obtained by defining the interconnection architecture between the subsystems based on the structural model diagram, including: Based on the module definition diagram, the hierarchical structure and dependencies between subsystems are defined, and based on the internal module diagram, the ports, interface protocols and message channels between subsystems are defined, thus obtaining the logical architecture model.

[0014] This invention provides a technical solution for a logical architecture model by defining the hierarchical structure and dependencies between subsystems based on a module definition diagram, and defining the ports, interface protocols, and message channels between subsystems based on an internal module diagram. This solves the technical problems of unclear hierarchical structure, difficulty in tracing dependencies, lack of standardized definitions for ports and interface protocols, and difficulty in unified management of message channels among vehicle, road, and cloud subsystems, which lead to difficulties in system integration. It realizes structured modeling of the interconnection architecture between subsystems and provides a clear foundation for the interconnection relationship for parameter configuration in the physical architecture.

[0015] In one optional implementation, the constraint model diagram is a parametric diagram, and the subsystem includes a vehicle terminal system, a roadside subsystem, and a cloud platform subsystem. The parameters of the vehicle terminal system include the vehicle speed parameters and the speed parameters of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters. The constraint model diagram defines the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems, resulting in a physical architecture model, including: Based on the parameter diagram, the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model.

[0016] This invention provides a technical solution for obtaining a physical architecture model based on parameter diagrams. This solution addresses the technical problems in high-speed early warning systems, such as the lack of unified constraints on parameter configuration, unclear calculation logic between parameters of different subsystems, and difficulty in quantifying and verifying system performance. It achieves a visual definition of the constraint relationships and calculation logic between parameters, providing a clear quantitative verification basis for subsequent simulation tests. The parameters of the vehicle-to-subsystem subsystem include the vehicle's own speed and the speed of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters.

[0017] In one optional implementation, the simulation test of the model file includes: The model file is simulated and tested in at least one simulation scenario, including a ramp merging scenario, a sudden accident scenario, a sensor failure scenario, a network jitter scenario, and a communication interruption scenario.

[0018] This invention addresses the technical problem of traditional system design struggling to verify the architecture's behavior under complex and extreme scenarios in the early stages, leading to high costs for later defect discovery and repair. It achieves full verification of the high-speed early warning system's operational behavior under various typical operating conditions and extreme conditions during the design phase, improving system reliability and robustness while reducing later repair costs.

[0019] In an optional implementation, the method further includes: If the comparison fails, at least one of the requirement model, the functional architecture model, the logical architecture model, and the physical architecture model shall be modified, and the simulation test shall be re-executed until the simulation test results satisfy the constraints.

[0020] This invention provides a technical solution that addresses the limitations of traditional system design in terms of optimization and improvement space after discovering defects and the difficulty in forming a design closed loop. This solution involves modifying at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model if the comparison fails, and re-executing the simulation test until the simulation test results satisfy the constraints. This achieves a closed-loop iterative mechanism for architecture design from modeling, simulation to verification and optimization, ensuring that the final output architecture solution meets the preset constraints and improving the reliability and completeness of the system design.

[0021] In a second aspect, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the construction method of the high-speed early warning system of the first aspect or any corresponding embodiment described above.

[0022] Thirdly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the construction method of the high-speed early warning system of the first aspect or any corresponding embodiment described above. Attached Figure Description

[0023] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the architecture design of a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 3 This is a system requirements analysis diagram of a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a use case of a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a module definition for a method of constructing a high-speed early warning system according to an embodiment of the present invention; Figure 7 This is a schematic diagram of an internal module of a method for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 8 This is a diagram defining a high-real-time collision warning module in a method for constructing a high-speed early warning system according to an embodiment of the present invention. Figure 9 This is a diagram showing the high real-time collision warning decision suggestion parameters of the construction method of the high-speed early warning system according to an embodiment of the present invention; Figure 10 This is a flowchart of the model simulation verification of the construction method of the high-speed early warning system according to an embodiment of the present invention; Figure 11 This is a schematic diagram of a capability set for a method of constructing a high-speed early warning system according to an embodiment of the present invention; Figure 12 This is a structural block diagram of a device for constructing a high-speed early warning system according to an embodiment of the present invention; Figure 13 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0027] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0028] Vehicle-road-cloud integration refers to the fusion of the physical and information spaces of people, vehicles, roads, and the cloud into a unified cyber-physical system. Based on collaborative perception, decision-making, and control, it aims to achieve safe, energy-efficient, comfortable, and highly efficient operation of intelligent connected vehicle transportation systems. Road-cloud integrated systems are characterized by high coupling among multiple disciplines, specialties, and entities, encompassing multiple subsystems such as vehicle-side, roadside, cloud platform, and communication networks. Their architectural design faces challenges such as real-time fusion of multi-source heterogeneous data and issues related to system reliability and verifiability.

[0029] In related technologies, the architecture design of collaborative early warning systems based on vehicle-road-cloud integration mainly follows traditional systems engineering methods, which rely on document-based structured decomposition and natural language description. However, as a complex large-scale system encompassing vehicles, roads, cloud, and network, the collaborative early warning system based on vehicle-road-cloud integration is characterized by high complexity, high overall investment, and significant social impact. In traditional document-based design methods, the design results of each design stage are fragmented, and the interface definitions, data flows, and timing constraints between vehicles, roads, and cloud lack executable formal descriptions, resulting in low collaboration and integration difficulties.

[0030] Based on this, the present invention provides an embodiment of a method for constructing a high-speed early warning system. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] This embodiment provides a method for constructing a high-speed early warning system. Figure 1 This is a flowchart of a method for constructing a high-speed early warning system according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the system requirements of the high-speed early warning system to be constructed, generate at least one requirement model diagram based on the system requirements, and construct a requirement model based on the requirement model diagram. The high-speed early warning system includes at least one subsystem.

[0032] Step S102: Decompose the top-level functions of the high-speed early warning system according to the system requirements to obtain at least one behavior model diagram. Define the interaction sequence between each subsystem based on the behavior model diagram to obtain the functional architecture model.

[0033] Step S103: Based on the interaction sequence defined in the behavior model diagram, extract the data flow and control flow between each subsystem, generate at least one structural model diagram based on the data flow and control flow, define the interconnection architecture between each subsystem based on the structural model diagram, and obtain the logical architecture model.

[0034] Step S104: Based on the functional requirements of each subsystem in the interconnection architecture, determine the parameters that need to be configured in each subsystem, and generate at least one constraint model diagram. Based on the constraint model diagram, define the constraint relationship between different parameters within the same subsystem and the calculation logic between parameters of different subsystems to obtain the physical architecture model.

[0035] Step S105: Output the requirement model, functional architecture model, logical architecture model, and physical architecture model as model files, perform simulation tests on the model files, and compare the simulation test results with the constraint relationships defined in the constraint model diagram. If the comparison passes, output the architecture scheme of the high-speed early warning system.

[0036] The method for constructing a high-speed early warning system provided in this embodiment solves the technical problem of low system synergy and integration difficulties caused by the lack of executable formal descriptions of interface definitions, data flow and timing constraints between vehicles, roads and the cloud, through the construction of a requirement model, functional architecture model, logical architecture model and physical architecture model, and the output of model files and simulation testing based on the data flow, control flow, interaction timing and parameter constraint relationships between each model. The method allows for simulation verification of the architecture scheme of the high-speed early warning system during the model design stage, and can compare the simulation test results with the constraint relationships defined in the constraint model diagram, thereby discovering and correcting architectural defects in the early stage of system development, improving the system's synergy and integration efficiency, and reducing the later repair costs.

[0037] Reference Figure 2 The diagram illustrates the architectural design of a method for constructing a high-speed early warning system according to an embodiment of the present invention. The architectural design process includes a requirements model design phase, a functional architecture design phase, a logical architecture design phase, a physical architecture design phase, a simulation model execution phase, and an architecture design evaluation phase.

[0038] In the requirements model design phase, the system requirements of the highway early warning system to be built are obtained, and a requirements model diagram is generated based on these requirements. The requirements model is then constructed based on this diagram. The highway early warning system includes a vehicle-side subsystem, a roadside subsystem, and a cloud platform subsystem. The requirements model diagram includes a requirements analysis diagram and a use case diagram. The requirements analysis diagram describes the hierarchical relationships between the requirements, and the use case diagram confirms the interrelationships between the requirements. The requirements model provides a unified requirements foundation for subsequent phases.

[0039] Reference Figure 4 This diagram illustrates a use case diagram of a method for constructing a high-speed early warning system according to an embodiment of the present invention. The use case diagram shows the main functional use cases of the high-speed collaborative early warning system and their interaction relationships with external participants, while also demonstrating the inclusion relationships between the use cases.

[0040] The high-speed collaborative early warning system serves as the system boundary, while vehicle drivers and roadside information broadcasting units act as external participants. Vehicle drivers, referring to those driving connected vehicles on highways, are the primary recipients and responders of early warning information. Roadside information broadcasting units, deployed along highways, are responsible for broadcasting road condition and early warning information to passing vehicles.

[0041] The high-speed collaborative early warning system comprises three top-level use cases: road traffic condition early warning, road hazard condition early warning, and road network control information early warning. Road traffic condition early warning refers to the functional use case that identifies congestion, slow traffic, and other conditions based on real-time traffic flow and issues warnings to vehicles. Road hazard condition early warning refers to the functional use case that identifies road obstacles, construction areas, severe weather, and other hazardous factors based on roadside perception data and issues warnings to vehicles. Road network control information early warning refers to the functional use case that integrates traffic control, accident, and weather information released by the traffic control center and issues warnings to vehicles.

[0042] The road traffic condition warning use case is linked to multiple sub-use cases through inclusion relationships, including traffic congestion warning, close following distance warning, lane change warning, and speeding warning. The traffic congestion warning is the function that prompts the vehicle to slow down when traffic congestion is detected ahead. The close following distance warning is the function that prompts the vehicle to avoid collision when the distance between the vehicle and the vehicle in front is less than a safe threshold. The lane change warning is the function that prompts the vehicle when a vehicle in an adjacent lane is approaching and a lane change poses a collision risk. The speeding warning is the function that prompts the vehicle to slow down when the vehicle's speed exceeds the speed limit of the road section.

[0043] The road hazard warning use case is linked to multiple sub-use cases through inclusion relationships, including road surface anomaly warning, construction area warning, severe weather warning, and tunnel-specific warning. The road surface anomaly warning is the function that issues a avoidance warning to vehicles when abnormal conditions such as water accumulation, ice, potholes, or debris are detected on the road surface. The construction area warning is the function that issues a slowdown and caution warning to vehicles when they approach a road construction area. The severe weather warning is the function that issues speed limit and safety warnings to vehicles when severe weather such as heavy fog, heavy rain, heavy snow, or strong winds are detected. The tunnel-specific warning is the function that issues speed limit, headlight activation, and distance maintenance warnings to vehicles when they enter a tunnel area.

[0044] The road network control information early warning use case is linked to multiple sub-use cases through inclusion relationships, including traffic control early warning, accident information early warning, weather information early warning, and special vehicle early warning. Traffic control early warning refers to the function of issuing detour prompts to vehicles when the traffic control center issues information on road closures, lane restrictions, or traffic diversions. Accident information early warning refers to the function of issuing slow-down and yield prompts to vehicles behind when a traffic accident occurs. Weather information early warning refers to the function of issuing warnings to vehicles when the meteorological department issues severe weather forecasts. Special vehicle early warning refers to the function of issuing yield prompts to surrounding vehicles when emergency vehicles such as ambulances, fire trucks, or police cars approach.

[0045] The execution results of the aforementioned warning use cases ultimately reach the vehicle driver through vehicle-side warning prompts. Vehicle-side warning prompts refer to the interactive function that presents the warning information generated by each use case to the driver in a visual, auditory, or tactile manner. The three top-level use cases—road traffic condition warning, road hazard condition warning, and road network control information warning—are all related to the vehicle-side warning prompt use cases through an inclusion relationship, indicating that regardless of the type of warning, the information ultimately needs to be delivered to the driver through vehicle-side warning prompts.

[0046] There is a correlation between vehicle drivers and all warning use cases, indicating that drivers are the end users of the warning service. The system provides warning information to drivers, who receive the warnings and take corresponding driving actions. There is also a correlation between roadside information broadcasting and road hazard warnings, indicating that roadside information broadcasting is an important data source for road hazard perception, and the system obtains real-time road surface status data through roadside information broadcasting.

[0047] During the functional architecture design phase, the top-level functions of the highway early warning system are decomposed based on the system requirements in the requirements model to obtain a behavioral model diagram. The interaction sequence between each subsystem is then defined based on the behavioral model diagram to obtain the functional architecture model. The behavioral model diagram includes activity diagrams and sequence diagrams. Activity diagrams describe the execution flow of each functional module in the early warning scenario, while sequence diagrams define the interaction sequence between the vehicle, roadside, and cloud platforms. The interaction sequence includes message format, triggering conditions, and timeout handling mechanisms.

[0048] During the logical architecture design phase, based on the interaction sequence defined in the functional architecture model, the data flow and control flow between each subsystem are extracted. A structural model diagram is generated based on the data flow and control flow, and the interconnection architecture between each subsystem is defined based on the structural model diagram, resulting in the logical architecture model. The structural model diagram includes a module definition diagram and an internal module diagram. The module definition diagram defines the hierarchical structure and dependencies between each subsystem, while the internal module diagram defines the ports, interface protocols, and message channels between each subsystem.

[0049] During the physical architecture design phase, based on the interconnection architecture in the logical architecture model, the parameters that need to be configured in each subsystem are determined, and a constraint model diagram is generated. Based on the constraint model diagram, the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined, resulting in the physical architecture model. The constraint model diagram is a parameter diagram. The parameters of the vehicle-side subsystem include the vehicle's speed and the speed of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters.

[0050] During the simulation model execution phase, the requirement model, functional architecture model, logical architecture model, and physical architecture model are output as model files, and simulation tests are performed on these model files. Simulation tests are executed under various simulation scenarios, including ramp merging scenarios, sudden accident scenarios, sensor failure scenarios, network jitter scenarios, and communication interruption scenarios. Key technical indicators are collected during the simulation tests, including early warning latency, decision consistency, and system response time.

[0051] During the architecture design evaluation phase, the simulation test results are compared with the constraint relationships defined in the constraint model diagram. If the comparison passes, the architecture scheme of the high-speed early warning system is output. If the comparison fails, at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model is modified, and the simulation test is re-executed until the simulation test results satisfy the constraint relationships. The modified model is then verified again through the simulation model execution phase, forming a closed-loop iterative process from architecture design to design verification and optimization.

[0052] The steps described above will be explained in detail below.

[0053] In step S101, the system requirements of the high-speed early warning system to be constructed are obtained, and at least one requirement model diagram is generated based on the system requirements. The requirement model is constructed based on the requirement model diagram. The high-speed early warning system includes at least one subsystem.

[0054] Specifically, the first step is to obtain the system requirements of the high-speed early warning system to be built. System requirements refer to the various requirements that the high-speed collaborative early warning system needs to meet, such as functional requirements, performance requirements, interface requirements, and constraint requirements. The high-speed early warning system refers to a system used to provide safety services such as collision warning and lane change warning to connected vehicles in highway scenarios.

[0055] The high-speed early warning system in this embodiment includes at least one subsystem. A subsystem refers to a component that constitutes the high-speed early warning system, including a vehicle-side subsystem, a roadside subsystem, and a cloud platform subsystem. Based on the acquired system requirements, at least one requirement model diagram is generated. The requirement model diagram is a graphical model describing system requirements using a system modeling language, including requirement analysis diagrams and use case diagrams. A requirement model is constructed based on the generated requirement model diagram. The requirement model is a structured expression of the system requirements, used to carry requirement information and its relationships.

[0056] In one implementation, the requirement model diagram includes a requirement analysis diagram and a use case diagram. At least one requirement model diagram is generated based on system requirements, and a requirement model is constructed based on the requirement model diagram, including: Extract the requirement information from the system requirements, and divide the requirement information into a top-level capability set and a sub-capability set corresponding to each top-level capability set according to the preset requirement dimensions; A requirement analysis diagram is generated based on the hierarchical relationship between the various requirement information, and a use case diagram is generated based on the correlation between the various requirement information. A requirement model is then constructed based on the requirement analysis diagram and the use case diagram.

[0057] In one implementation, the requirement model diagram includes a requirement analysis diagram and a use case diagram. The requirement analysis diagram describes the hierarchical relationships between requirements, while the use case diagram describes the relationships between requirements and the interactions between the system and external stakeholders. The specific process of generating at least one requirement model diagram based on system requirements and constructing the requirement model based on the requirement model diagram is as follows: Reference Figure 3 This diagram illustrates a system requirements analysis method for constructing a high-speed early warning system according to an embodiment of the present invention. First, requirement information is extracted from the system requirements. This requirement information consists of original requirement items obtained from user requirement documents, technical standards, laws and regulations, etc. Then, the requirement information is divided into at least one top-level capability set according to requirement dimensions such as strategic requirements, regulatory requirements, stakeholder requirements, service requirements, system requirements, and scenario requirements. Specifically, strategic requirements refer to the macro-level goals and directional requirements of system construction; regulatory requirements refer to the laws, regulations, and standards that the system must comply with; stakeholder requirements refer to the expectations and requirements of relevant parties such as drivers, traffic control centers, and highway operators; service requirements refer to the specific service capabilities that the system needs to provide to users; system requirements refer to the technical performance and functional characteristics that the system itself should possess; and scenario requirements refer to the operational requirements that the system should meet under different traffic scenarios. Each top-level capability set corresponds to one or more sub-capability sets, which are further refinements and decompositions of the top-level capability sets. One requirement piece of information corresponds to one or more capability sets; that is, one requirement may belong to one capability set or multiple capability sets simultaneously.

[0058] A requirements analysis diagram is generated based on the hierarchical relationships between various requirements. These hierarchical relationships refer to the inclusion, derivation, and refinement relationships between requirements. For example, a top-level capability set may contain sub-capability sets. System requirements are derived from stakeholder requirements. The requirements analysis diagram graphically displays the hierarchical structure between requirements, facilitating understanding and tracing system requirements.

[0059] Reference Figure 11 This paper illustrates a capability set diagram of a method for constructing a high-speed early warning system according to an embodiment of the present invention, showing multiple capability set entries related to vehicle driving safety and their derivation relationships.

[0060] The Driving Safety Assistance Control Service Capability Set is one of the top-level capability sets. This set requires the system to possess the ability to provide early warnings and real-time alerts for abnormal road traffic conditions, abnormal vehicle operation, and abnormal changes in severe weather and road conditions, in order to minimize losses caused by traffic anomalies. Abnormal road traffic conditions refer to abnormal fluctuations in traffic flow, road congestion, or reduced traffic capacity. Abnormal vehicle operation refers to dangerous driving behaviors such as speeding, sudden acceleration, sudden deceleration, or abnormal lane changes by a single vehicle. Abnormal changes in severe weather and road conditions refer to adverse conditions such as heavy fog, heavy rain, heavy snow, strong winds, icy roads, or flooded roads. Early warning refers to the ability to alert the driver before a risk event occurs. Real-time alerts refer to the ability to immediately alert the driver when a risk event occurs.

[0061] The driving safety information early warning service capability set is a sub-capability set derived from the driving safety auxiliary control service capability set. The driving safety information early warning service capability set requires that, for vehicles with service receiving capabilities, the system should possess the service capability to control the vehicle in emergency situations, including braking control, steering control, and throttle control capabilities. Vehicles with service receiving capabilities refer to connected vehicles equipped with communication units and actuator controllers, capable of receiving control commands from the cloud and executing corresponding vehicle control operations. An emergency situation refers to a situation where a collision is imminent or the vehicle is already in a dangerous state and the driver cannot react in time. Braking control capability refers to the system's ability to automatically send deceleration or emergency braking commands to the vehicle's braking system. Steering control capability refers to the system's ability to automatically send avoidance direction commands to the vehicle's steering system. Throttle control capability refers to the system's ability to automatically send reduction or cut-off power output commands to the vehicle's powertrain system.

[0062] The enhanced perception service capability set is another sub-capability set derived from the driving safety assistance control service capability set. This enhanced perception service capability set requires the system to possess the ability to correlate and match roadside perception results with heterogeneous data from connected vehicles by calculating indicators such as position distance, speed similarity, and heading angle. Position distance refers to the spatial distance difference between the roadside perceived target and the target reported by the vehicle. Speed ​​similarity refers to the degree of consistency between the speed of the roadside perceived target and the speed of the target reported by the vehicle. Heading angle refers to the angular difference between the travel direction of the roadside perceived target and the travel direction of the target reported by the vehicle. Roadside perception results refer to target information detected by roadside sensors such as radar and cameras. Heterogeneous data from connected vehicles refers to vehicle status information uploaded by connected vehicles through communication networks; its data format and acquisition method differ from roadside perception data. Correlation and matching refers to the ability to correspond and bind roadside perception results with the same physical target in the data reported by connected vehicles.

[0063] The connected vehicle data and roadside data fusion service capability set is a sub-capability set derived from the enhanced perception service capability set. This set requires the system to possess the ability to provide data for centralized cloud-based decision-making using real-time vehicle and road condition data, and to provide the decision results to vehicles in the form of standardized application programming interfaces (APIs). Real-time vehicle and road condition data refers to vehicle status data reported by connected vehicles and environmental data collected by roadside sensing devices. Centralized cloud-based decision-making refers to unified decisions made after fusing and analyzing multi-source data on a cloud platform. Standardized APIs refer to service call interfaces that follow unified specifications, facilitating access to system services by vehicles of different models and brands. The enhanced perception decision suggestion service capability set is a further sub-capability set derived from the connected vehicle data and roadside data fusion service capability set, used to supplement and improve the perception decision-making service capabilities.

[0064] This capability set diagram illustrates the hierarchical and derivational relationships between capability set items in the form of a demand diagram, clarifying the derivational chains between capability sets.

[0065] Next, use case diagrams are generated based on the relationships between the various requirements. Relationships refer to the mutual relationships and dependencies between requirements, between requirements and use cases, and between use cases and actors. Use case diagrams graphically display the functional boundaries of the system, external actors, and use cases provided by the system. Through use case diagrams, the relationships between various requirements can be confirmed, ensuring that each requirement is covered by at least one use case.

[0066] Furthermore, a requirement model is constructed based on the requirement analysis diagram and use case diagram. The requirement model stores the requirement analysis diagram, use case diagram, and the mapping relationship between requirements in a unified manner, forming a traceable and reusable requirement asset, which provides input for subsequent functional architecture design.

[0067] For example, in the specific implementation, the technical scenario of the high-speed collaborative early warning system is first analyzed. The technical scenario refers to the actual operating environment and conditions of the high-speed early warning system, including multi-source inputs such as data reported by connected vehicles, data from roadside sensing devices, and traffic control data. Among them, data reported by connected vehicles refers to vehicle status information such as operating trajectory, speed, and steering uploaded in real time by connected vehicles through communication networks; data from roadside sensing devices refers to environmental information such as traffic flow, vehicle position, and obstacles collected by sensors such as radars and cameras deployed along the highway; and traffic control data refers to management data such as traffic control, accident information, and meteorological information released by the traffic control center.

[0068] Modeling tools such as Enterprise Architect can be used to extract textual information from requirements. Enterprise Architect is a modeling software that supports system modeling languages ​​and is used to create and manage system models. Textual information refers to the content of the requirements document described in natural language. Classifying textual information into corresponding sub-capability sets achieves structured organization of requirements information.

[0069] Next, the relationships between requirement information are established through requirement analysis diagrams and use case diagrams, mapping the requirements to subsequent functional and interface definitions. Functional definitions refer to determining the specific functional modules the system needs to implement based on the requirements, while interface definitions refer to determining the interaction methods and communication protocols between subsystems based on the requirements. Requirement modeling achieves a graphical description of system requirements, while also satisfying the language characteristics of system modeling languages ​​to describe functional, performance, interface, and constraint requirements. Specifically, functional requirements refer to the operations or services the system should perform; performance requirements refer to quantitative indicators such as response time, throughput, and reliability; interface requirements refer to the protocols, data formats, and communication methods followed when the system interacts with external entities; and constraint requirements refer to the limitations that the system design must adhere to, such as hardware resource limitations and communication bandwidth limitations.

[0070] This embodiment extracts requirement information from system requirements, divides the requirement information into a top-level capability set and sub-capability sets corresponding to each top-level capability set according to preset requirement dimensions, and generates a requirement analysis diagram based on the hierarchical relationship between each requirement information and a use case diagram based on the correlation between each requirement information. The technical solution of constructing a requirement model based on the requirement analysis diagram and use case diagram solves the technical problems of unclear classification of requirement information, difficulty in visually expressing hierarchical relationships and correlations, leading to misunderstandings of requirements and low communication efficiency in traditional documented requirement analysis. It realizes the structured classification, hierarchical display and correlation confirmation of requirement information, and improves the accuracy and traceability of requirement analysis.

[0071] In step S102, the top-level functions of the high-speed early warning system are decomposed according to system requirements to obtain at least one behavior model diagram. Based on the behavior model diagram, the interaction sequence between each subsystem is defined to obtain a functional architecture model.

[0072] Top-level functionality refers to the highest-level system function description of the high-speed early warning system. Behavioral model diagrams are graphical models describing the dynamic behavior of the system using system modeling languages, including activity diagrams and sequence diagrams. Interaction sequence refers to the temporal message transmission and collaboration relationships between the vehicle-side subsystems, roadside subsystems, and cloud platform subsystems. The functional architecture model is an architectural view describing the system's functional components and the interaction relationships between these functions.

[0073] This embodiment decomposes the top-level functions of the high-speed early warning system using a structured decomposition approach, i.e., a top-down, layer-by-layer breakdown. The decomposition path is from the overall system to subsystems, from subsystems to functional modules, and from functional modules to sub-functions. Structured decomposition is a systematic analysis method that refines functions level by level according to the system's composition hierarchy. The logical elements are the four logical elements required for business operations: perception, analysis, dissemination, and handling, formed through business processes. Specifically, data access and data aggregation functions belong to the perception stage, data processing and decision calculation functions belong to the analysis stage, information dissemination functions belong to the dissemination stage, and information feedback and data display functions belong to the handling stage.

[0074] Reference Figure 5 This diagram illustrates a sequence diagram of a method for constructing a high-speed early warning system according to an embodiment of the present invention. The sequence diagram shows the timing of interactions between various functional modules in the high-speed early warning system and between the vehicle-side, roadside, and cloud platforms.

[0075] like Figure 5 As shown, the interaction process of the highway early warning system unfolds from top to bottom in chronological order. The participants involved in the interaction process include roadside equipment, vehicle terminals, and multiple functional modules within the cloud platform. The functional modules within the cloud platform include a data access module, a data aggregation module, a data processing module, a decision calculation module, an information dissemination module, an information feedback module, and a data display module.

[0076] In the first phase of the interaction process, the roadside equipment sends roadside sensing data to the data access module, while the vehicle-mounted device simultaneously sends vehicle operation data to the same module. Roadside sensing data refers to environmental information collected by the roadside sensing equipment, including vehicle location, speed, and lane information. Vehicle operation data refers to vehicle status information reported by connected vehicles, including their trajectory and vehicle-mounted sensing data. Before data transmission, roadside equipment and the cloud platform perform security authentication, and vehicle-mounted device and the cloud platform perform vehicle security authentication. These security authentications verify the legitimacy of both communicating parties, preventing unauthorized devices from accessing the system.

[0077] After receiving roadside sensing data and vehicle operation data, the data access module transmits this data to the data aggregation module. The data aggregation module collects and integrates the multi-source data to form vehicle fusion data. Vehicle fusion data refers to the comprehensive dataset obtained by spatiotemporally aligning and correlating roadside sensing data and vehicle operation data. The data aggregation module then transmits the vehicle fusion data to the data processing module.

[0078] The data processing module performs cleaning, filtering, and feature extraction on the fused vehicle data, then transmits the processed data to the decision-making module. Based on the processed data, the decision-making module identifies risks and determines early warnings, generating collaborative early warning events. Collaborative early warning events refer to risk events identified by the system that require warnings, including collision risk events, lane change conflict events, and abnormal driving events. The decision-making module then transmits these collaborative early warning events to the information dissemination module.

[0079] The information dissemination module generates collaborative early warning information based on the collaborative early warning event and sends this information to the vehicle. The collaborative early warning information refers to the warning notification sent to the vehicle, including the risk type, risk level, and driving suggestions. After receiving the collaborative early warning information, the vehicle sends service response information back to the information feedback module. Service response information refers to the vehicle's confirmation of receipt and handling of the early warning information. The information feedback module then passes the service response information to the data display module.

[0080] The data visualization module also receives collaborative early warning events from the decision computing module. It presents these events and service response information to operations and management personnel in a visual manner, enabling them to monitor system operation and early warning handling.

[0081] The entire interaction process embodies the complete business loop of the high-speed early warning system, from data acquisition, data aggregation, data processing, decision calculation, information dissemination to information feedback and data display. The sequence diagram clearly defines the message transmission order, message content, and triggering conditions between each functional module, providing interaction specifications for the subsequent interconnection architecture definition in the logical architecture.

[0082] In one implementation, the top-level functions of the high-speed early warning system are decomposed according to system requirements to obtain at least one behavioral model diagram, including: Based on system requirements, the high-speed early warning system is decomposed layer by layer from the overall system to subsystems, from subsystems to functional modules, and from functional modules to sub-functions, to obtain at least one system function of the high-speed early warning system; Based on the business process of the high-speed early warning system, determine the logical elements, and generate at least one behavioral model diagram according to the system functions, logical elements, and the execution order between the system functions.

[0083] Specifically, based on system requirements, the highway early warning system is decomposed layer by layer from the overall system to subsystems, from subsystems to functional modules, and from functional modules to sub-functions, resulting in at least one system function of the highway early warning system. The overall system refers to the complete highway early warning system as a whole. Subsystems refer to the next level of systems that constitute the overall system, including vehicle terminal subsystems, roadside subsystems, and cloud platform subsystems. Functional modules refer to functional units within subsystems that perform specific duties, and sub-functions refer to smaller, more granular functional units further subdivided within functional modules. Therefore, this embodiment employs a system analysis method from abstract to concrete and from macro to micro, ensuring the completeness and consistency of the functional division.

[0084] By decomposing the data layer by layer, at least one system function of the high-speed early warning system is obtained, such as data access, data aggregation, data processing, decision calculation, information dissemination, information feedback, and data display. Specifically, the data access function receives multi-source inputs, including data reported by connected vehicles, data from roadside sensing devices, and traffic control data; the data aggregation function collects and integrates data from different data sources; the data processing function performs cleaning, filtering, and fusion operations on the aggregated data; the decision calculation function identifies risks and generates early warning decisions based on the processed data; the information dissemination function sends early warning information to target vehicles or relevant parties; the information feedback function receives confirmation of the vehicle's response to the early warning information and the results of its handling; and the data display function presents information such as early warning events and system status to operation and management personnel in a visual manner.

[0085] Furthermore, logical elements are determined according to the business process of the highway early warning system. The business process refers to the complete business chain of the highway early warning system from data collection to early warning response, which may include the perception stage, analysis stage, dissemination stage, and response stage. Among them, the perception stage is responsible for collecting raw data such as vehicle status and roadside environment; the analysis stage is responsible for analyzing and processing the perceived data and making decisions; the dissemination stage is responsible for pushing the decision results to the target objects in the form of early warning information; the response stage is responsible for receiving response feedback and displaying the system's operating status; logical elements are abstract summaries of each stage in the business process, used to guide the classification and organization of functional modules.

[0086] Finally, at least one behavioral model diagram is generated based on system functions, logical elements, and the execution order among these functions. The execution order refers to the sequence in which each system function appears in the business process; for example, data access precedes data aggregation, data aggregation precedes data processing, data processing precedes decision calculation, and decision calculation precedes information dissemination. The behavioral model diagram is generated based on the division of system functions, the classification of logical elements, and the execution order among these functions, and is used to describe the dynamic behavior of the system.

[0087] This embodiment solves the technical problems of inconsistent granularity, difficulty in clearly expressing the execution order and logical relationships between functions, and inconsistencies in understanding system behavior in traditional function decomposition. It achieves top-down structured decomposition of system functions and visualized modeling of function execution processes, providing a clear behavioral basis for defining the interaction sequence between subsequent subsystems.

[0088] In one implementation, the behavioral model diagram includes an activity diagram and a sequence diagram. Based on the behavioral model diagram, the interaction sequence between each subsystem is defined to obtain a functional architecture model, including: Based on the activity diagram, determine the execution flow of each functional module of the high-speed early warning system to be built under the preset early warning scenario. The execution flow includes data flow and control flow. The interaction sequence between subsystems is defined based on the sequence diagram, and the functional architecture model is obtained based on the execution flow and interaction sequence. The interaction sequence includes message format, triggering conditions and timeout handling mechanism.

[0089] The behavioral model diagram in this embodiment includes an activity diagram and a sequence diagram. The activity diagram is used to graphically describe the execution flow of the system, such as execution order, branch conditions, and parallel behavior. The sequence diagram is used to describe the interaction sequence between subsystems in chronological order. When constructing the functional architecture model, the execution flow of each functional module of the highway early warning system to be constructed is first determined based on the activity diagram under preset early warning scenarios. The early warning scenario refers to traffic conditions that may trigger early warning services, including rear-end collision risk, ramp merging conflict, and abnormal driving behavior. The execution flow includes data flow and control flow. Data flow refers to the path and direction of data transmission between functional modules, such as roadside perception data flowing from the roadside subsystem to the cloud platform subsystem. Control flow refers to the order and conditions of control commands or status signals transmitted between functional modules, such as triggering the information release function after the early warning decision is completed.

[0090] Furthermore, based on the sequence diagram, the interaction sequence between each subsystem is defined. In this embodiment, the subsystems include the vehicle terminal system, the roadside subsystem, and the cloud platform subsystem. The interaction sequence includes message format, triggering conditions, and timeout handling mechanism. The message format refers to the organization and encoding method of data transmission between subsystems; the triggering condition refers to the preconditions that must be met to initiate an interaction, such as triggering a warning when the collision time is less than a safety threshold; the timeout handling mechanism refers to the measures taken by the system when an interaction request does not receive a response within a specified time, such as resending the message or downgrading the processing.

[0091] Finally, based on the execution flow determined by the activity diagram and the interaction sequence defined by the sequence diagram, the functional architecture model is obtained. The functional architecture model integrates the execution flow of functional modules and the interaction sequence between subsystems, and fully describes the dynamic behavior of the high-speed early warning system in the early warning scenario.

[0092] In practical implementation, through deep collaboration among roadside intelligent facilities, vehicle-mounted terminals, communication networks, and cloud control platforms, real-time monitoring of traffic flow, vehicle status, road environment, and weather conditions across the entire highway is achieved. Roadside intelligent facilities refer to equipment such as radars, cameras, and roadside computing units deployed along the highway; vehicle-mounted terminals refer to communication and processing units installed on vehicles; communication networks refer to the network infrastructure supporting data transmission between vehicles, roads, and the cloud, which may include C-V2X networks and 5G networks; the cloud control platform refers to a centralized control and data processing platform deployed in the cloud; and real-time monitoring across the entire highway refers to the continuous perception and collection of traffic elements throughout the entire highway route.

[0093] After identifying potential risks through artificial intelligence analysis, early warning information is accurately, hierarchically, and proactively pushed to multiple stakeholders, including drivers, vehicles, traffic management departments, operating units, and rescue organizations, via C-V2X or 5G low-latency networks. This forms a closed-loop safety system encompassing monitoring, assessment, early warning, response, and feedback. Monitoring refers to the continuous perception of traffic conditions; assessment refers to the analysis of perceived data and risk judgment; early warning refers to issuing risk alerts to relevant parties; response refers to the corresponding measures taken by relevant parties; and feedback refers to transmitting the response results back to the system.

[0094] This embodiment determines the execution flow of each functional module of the high-speed early warning system under a preset early warning scenario based on an activity diagram. This execution flow includes data flow and control flow, and defines the interaction sequence between each subsystem based on a sequence diagram. This interaction sequence includes message format, triggering conditions, and timeout handling mechanism. Based on the execution flow and interaction sequence, a technical solution for obtaining the functional architecture model is obtained. This solves the technical problems of unclear functional execution flow and lack of standardized description of interaction sequence between vehicle, road, and cloud subsystems, resulting in low system synergy. It realizes unified modeling of functional module execution flow and subsystem interaction sequence, and provides a complete interaction specification for the definition of interconnection architecture in the logical architecture.

[0095] In step S103, based on the interaction timing defined in the behavioral model diagram, the data flow and control flow between each subsystem are extracted, at least one structural model diagram is generated based on the data flow and control flow, and the interconnection architecture between each subsystem is defined based on the structural model diagram to obtain the logical architecture model.

[0096] The interaction sequence defined in the behavioral model diagram refers to the temporal message transmission and collaboration relationships between the vehicle terminal system, roadside subsystem, and cloud platform subsystem, including message format, triggering conditions, and timeout handling mechanisms. Data flow and control flow between subsystems are extracted from the interaction sequence. Data flow refers to the path of business data or perceived information transmitted between subsystems, while control flow refers to the sequence of control commands or status signals transmitted between subsystems.

[0097] Based on the extracted data flow and control flow, at least one structural model diagram is generated. This structural model diagram is a graphical model describing the static structure of the system using a system modeling language, including module definition diagrams and internal module diagrams. Based on the generated structural model diagrams, an interconnection architecture is defined between the subsystems. This interconnection architecture refers to the overall structural scheme for the interconnection and collaborative operation of multiple subsystems. Then, based on the defined interconnection architecture, a logical architecture model is obtained. This logical architecture model is an architectural view describing the components of the system and their interrelationships.

[0098] Figure 6 This is a schematic diagram illustrating a module definition of a method for constructing a high-speed early warning system according to an embodiment of the present invention. The schematic diagram shows the modular structure of the high-speed collaborative early warning system and the combination relationships between the modules.

[0099] The high-speed collaborative early warning system, as the top-level module, comprises four core components: a data management module, a collaborative decision-making algorithm module, an operations management module, and a network communication module. The data management module is responsible for the access, processing, storage, and quality control of all data within the system. The collaborative decision-making algorithm module is responsible for risk identification and early warning decisions based on multi-source fusion data. The operations management module is responsible for operational support functions such as equipment management, vehicle management, and data display. The network communication module is responsible for managing the data transmission channels between the vehicle, roadside, and cloud platforms.

[0100] The data management module comprises four sub-modules: data quality management, data processing, data storage, and collaborative perception. The data quality management sub-module is responsible for verifying and evaluating the accuracy, completeness, and timeliness of the incoming data, and feeding back the quality assessment results to the data source. The data processing sub-module performs cleaning, filtering, format conversion, and feature extraction on the raw data. The data storage sub-module is responsible for classifying, storing, and indexing the processed data, supporting subsequent data queries and analysis. The collaborative perception sub-module is responsible for spatiotemporal alignment and correlation fusion of multi-source perception data from vehicles and roadsides to form a unified understanding of the traffic environment.

[0101] The collaborative decision-making algorithm module comprises three sub-modules: a collaborative decision-making sub-module and a collaborative arbitration sub-module. The collaborative decision-making sub-module is responsible for risk identification and early warning level determination based on the fused perception data, outputting preliminary decision suggestions. The collaborative arbitration sub-module is responsible for adjudicating conflicts between multiple decision sources; for example, when vehicle-side decisions differ from cloud-based decisions, it selects the optimal decision result according to preset rules.

[0102] The operations management module comprises three sub-modules: roadside equipment management, connected vehicle management, and operations data display. The roadside equipment management sub-module is responsible for registering, configuring, monitoring the status of, and handling faults of radar, cameras, roadside computing units, and other equipment deployed along the highway. The connected vehicle management sub-module is responsible for authenticating, managing permissions, and tracking the service status of connected vehicles subscribed to the system's early warning service. The operations data display sub-module presents operational data, such as early warning events, equipment status, and vehicle information, to operations management personnel in a visual manner.

[0103] The data access module comprises three sub-modules: the vehicle-to-cloud gateway sub-module, the road-to-cloud gateway sub-module, and the cloud-to-cloud gateway sub-module. The vehicle-to-cloud gateway sub-module handles data transmission between connected vehicles and the cloud platform, including receiving vehicle-reported data and issuing warning information. The road-to-cloud gateway sub-module handles data transmission between roadside sensing devices and the cloud platform, including reporting roadside sensing data and issuing control commands. The cloud-to-cloud gateway sub-module handles data exchange between this system's cloud platform and external cloud platforms, such as data integration with traffic control center cloud platforms and meteorological service cloud platforms.

[0104] Reference Figure 7 This diagram illustrates an internal module schematic of a method for constructing a high-speed early warning system according to an embodiment of the present invention. The high-speed collaborative early warning system, as a whole module, comprises four components: a data access module, a data management module, a collaborative decision-making algorithm module, and an operation management module. The diagram details the interaction relationships between these modules using ports and connectors.

[0105] Connected vehicles, as external entities, connect to the data access module via a vehicle-cloud gateway. Connected vehicles refer to intelligent connected vehicles equipped with communication units and subscribing to system early warning services. Connected vehicles provide the system with reported vehicle data, including real-time operational status information such as vehicle position, speed, heading angle, and acceleration. This reported data enters the data access module through the vehicle-cloud gateway, which is responsible for protocol conversion and communication management of data access.

[0106] Roadside sensing devices, as external entities, connect to the data access module via a road-cloud gateway. Roadside sensing devices refer to data collection equipment such as radars, cameras, and weather sensors deployed along highways. These devices provide the system with roadside sensing data, including traffic flow, vehicle trajectories, lane occupancy, road surface conditions, and weather conditions. This data enters the data access module through the road-cloud gateway, which is responsible for the access and aggregation of roadside data.

[0107] After receiving data from the vehicle and roadside, the data access module transmits the data to the data management module. The data management module internally comprises a data processing submodule, a data storage submodule, and a data quality management submodule. The data processing submodule is responsible for cleaning, filtering, format conversion, and feature extraction of the raw data. The data storage submodule is responsible for persistent storage and index management of the processed data. The data quality management submodule is responsible for verifying the accuracy, completeness, and timeliness of the accessed data and feeding back the quality assessment results to the data access module.

[0108] After fusing vehicle-side and roadside data, the data management module generates vehicle-road fusion data and transmits it to the collaborative decision-making algorithm module. Vehicle-road fusion data refers to a comprehensive dataset obtained by spatiotemporally aligning and correlating vehicle-reported data with roadside perception data, containing more complete and reliable traffic environment cognitive information.

[0109] The collaborative decision-making algorithm module comprises three sub-modules: a fusion perception sub-module, a collaborative decision-making sub-module, and a decision arbitration sub-module. The fusion perception sub-module is responsible for deep perception analysis of multi-source fusion data from the data management module, identifying key elements and potential risks in traffic scenarios. The output of the fusion perception sub-module is transmitted to the collaborative decision-making sub-module. The collaborative decision-making sub-module is responsible for determining risk levels and generating early warning strategies based on the scenario understanding results output by the fusion perception sub-module, providing preliminary decision suggestions. The decision arbitration sub-module is responsible for adjudicating conflicts between multiple decision sources; for example, when vehicle-side decisions differ from cloud-based decisions, it selects the optimal decision result according to preset rules. The collaborative decision-making algorithm module ultimately outputs an early warning information service, which refers to early warning notifications generated by the system based on risk analysis results, including information such as early warning type, risk level, and suggested actions.

[0110] The early warning information service is distributed to different target objects through vehicle-to-cloud gateways, cloud-to-cloud gateways, and road-to-cloud gateways. The vehicle-to-cloud gateway distributes the service to connected vehicles, which then alert the driver via their in-vehicle human-machine interface. The road-to-cloud gateway distributes the service to roadside information broadcasting equipment, which then broadcasts it to passing vehicles. The cloud-to-cloud gateway shares the service with other cloud platforms, such as traffic control center cloud platforms or third-party service cloud platforms.

[0111] The operations management module interacts with external entities: highway management companies and vehicle manufacturers. Highway management companies are organizations responsible for highway operation and management. They report equipment registration information through the interfaces provided by the operations management module. This registration information includes the identification, location, type, and technical parameters of the roadside equipment. The operations management module internally includes a roadside equipment management submodule, an access vehicle management submodule, and an operations data display submodule. The roadside equipment management submodule manages equipment registration information and monitors the operational status of the equipment. The access vehicle management submodule manages vehicle registration information and performs identity authentication and service authorization for connected vehicles accessing the system. Vehicle manufacturers are the companies that produce connected vehicles. They provide vehicle registration information to the operations management module through a cloud gateway. This registration information includes the vehicle's identification, model, communication capabilities, and security certificates.

[0112] The high-speed collaborative early warning system interacts with external systems through three types of gateway ports. The vehicle-to-cloud gateway port handles data transmission and reception with connected vehicles. The road-to-cloud gateway port handles data transmission and reception with roadside sensing devices and roadside information broadcasting devices. The cloud-to-cloud gateway port handles data exchange with other cloud platforms. Each gateway port defines a clear interface protocol and message format to ensure reliable data transmission between different systems.

[0113] In one implementation, the structural model diagram includes a module definition diagram and an internal module diagram, and the interconnection architecture includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between the subsystems. Based on the structural model diagram, the interconnection architecture between the subsystems is defined, resulting in a logical architecture model, including: The hierarchical structure and dependencies between subsystems are defined based on the module definition graph, and the ports, interface protocols and message channels between subsystems are defined based on the internal module graph, resulting in a logical architecture model.

[0114] The structural model diagram in this embodiment includes a module definition diagram and an internal module diagram. The module definition diagram defines the composition structure of the system modules and the static relationships between them, while the internal module diagram defines the connections and interactions between the components within a module. The interconnection architecture includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between subsystems. The hierarchical structure refers to the hierarchical and subordinate relationships of each subsystem within the system organization. Dependencies refer to the association relationship where one subsystem's operation depends on another subsystem providing services or data. Ports are access points where subsystems provide external interfaces for receiving input and sending output. Interface protocols refer to the data formats, encoding rules, and transmission standards that subsystems must adhere to when communicating. Message channels are the logical paths or physical links for transmitting messages between subsystems.

[0115] When constructing the logical architecture model, the hierarchical structure and dependencies between subsystems are first defined based on a module definition diagram. The module definition diagram graphically displays the system's modular components and the relationships between them. Specifically, in the module definition diagram, the highway early warning system can be defined as the overall system module, and the vehicle terminal subsystem, roadside subsystem, and cloud platform subsystem can be defined as components of the overall system module. Furthermore, the hierarchical structure between subsystems can be described through composition or aggregation relationships in the module definition diagram; for example, the vehicle terminal subsystem, roadside subsystem, and cloud platform subsystem together constitute the highway early warning system. The dependencies between subsystems are described through the dependencies in the module definition diagram; for example, the cloud platform subsystem depends on the perception data provided by the roadside subsystem, and the vehicle terminal subsystem depends on the early warning information issued by the cloud platform subsystem.

[0116] Finally, based on the internal module diagram, the ports, interface protocols, and message channels between each subsystem are defined. The internal module diagram can graphically display the connection relationships between the components within a module. Specifically, the internal module diagram defines the external interaction ports for each subsystem. Ports include input ports and output ports. Input ports are used to receive data or messages from other subsystems, and output ports are used to send data or messages to other subsystems. Interface protocols define the rules to be followed when communicating through ports, including the selection of transport protocols, data serialization methods, and error handling mechanisms. Message channels define the pathways between ports, with each message channel carrying a specific type of data flow or control flow. Based on the hierarchical structure and dependencies defined in the module definition diagram, as well as the ports, interface protocols, and message channels defined in the internal module diagram, a logical architecture model is obtained.

[0117] In practical implementation, a system structure model is established based on the functional requirements of each subsystem. The subsystem functional requirements refer to the responsibilities and tasks that the vehicle-mounted terminal system, roadside subsystem, and cloud platform subsystem must undertake. The system structure model is an abstract description of the system's components and their interrelationships, including component definitions, interface definitions, and interaction method definitions. The functional elements and coupling rules of the high-speed collaborative early warning system can be deconstructed using object-oriented modeling methods. Object-oriented modeling views the system as multiple objects and their interactions, where each object encapsulates data and operations. Functional elements are the smallest units constituting system functions, and coupling rules refer to the rules governing the interdependence and mutual influence among functional elements.

[0118] At least one model set is established through object description, such as a data access model set, a data management model set, a collaborative decision-making algorithm model set, and an operations management model set. A model set is a logical grouping of a set of related models, used to organize and manage model elements. Specifically, the data access model set contains models related to multi-source data reception and parsing; the data management model set contains models related to data storage, data quality management, and data distribution; the collaborative decision-making algorithm model set contains models related to risk identification, early warning determination, and decision generation; and the operations management model set contains models related to equipment management, vehicle management, and event display.

[0119] Next, a system module definition diagram can be generated to describe the hierarchical structure of the top-level system. This hierarchical structure refers to the organizational structure and subordinate relationships between system modules. Subsystem inputs in the design process need to be optimized. Subsystem inputs refer to the data, commands, or configuration information received by each subsystem from external sources. Adjustments to the input content, format, or timing are necessary to improve system efficiency or reduce coupling. Furthermore, the interface definitions of the subsystems need to be refined. These subsystems include vehicle terminal subsystems, roadside subsystems, and cloud platform subsystems.

[0120] In this embodiment, the connected vehicle and the vehicle-cloud gateway communicate using the Transmission Control Protocol (TCP). The vehicle-cloud gateway is a communication access device deployed at the edge of the cloud platform, responsible for handling data exchange with the connected vehicle. The roadside sensing device and the roadside-cloud gateway communicate using the Message Queuing Telemetry Transport Protocol (MQTT). The roadside-cloud gateway is also a communication access device deployed at the edge of the cloud platform, responsible for handling data exchange with the roadside sensing device. The various modules within the highway warning system also communicate using the MQTT protocol. An internal module diagram can be generated to define the ports and interaction interfaces of the subsystems. A port is the access point for the subsystem to interact with the outside world, and an interaction interface is a set of services or operations provided by the port.

[0121] Next, we will use road network control information early warning as an example. Road network control information early warning refers to the early warning service issued to vehicles based on traffic control information within the highway network. The collaborative early warning system integrates real-time vehicle-road data and data from relevant functional departments such as traffic control, and generates decision service information through a collaborative decision-making algorithm, which is then sent to the corresponding vehicles. Real-time vehicle-road data includes vehicle status data reported by connected vehicles and environmental data collected by roadside sensing devices. Data from relevant functional departments of traffic control includes traffic control information, accident information, and meteorological information released by the traffic control center. The collaborative decision-making algorithm is the computing logic running on a cloud platform, used to fuse and analyze multi-source data and generate early warning decisions. The decision service information is the early warning result and driving suggestions output by the collaborative decision-making algorithm.

[0122] Connected vehicles provide real-time vehicle-reported data, such as driving trajectories and vehicle-end perception data. Driving trajectories refer to a continuous sequence of vehicle location points, while vehicle-end perception data refers to environmental information collected by the vehicle's own sensors. Roadside sensing devices provide real-time roadside sensing data, such as vehicle position, speed, and acceleration. The data management module is responsible for cleaning, verifying, and storing the received vehicle-reported data and real-time roadside sensing data. Then, the processed vehicle-reported data and real-time roadside sensing data are fused to obtain vehicle-road fusion data.

[0123] Next, the collaborative decision-making computing module performs early warning identification on the vehicle-road fusion data, detecting potential dangerous events from the fusion data and generating driving suggestions such as recommended speed and steering, which are then sent to relevant vehicles. Vehicle-road fusion data refers to a comprehensive dataset obtained by spatiotemporally aligning and correlating vehicle-reported data with roadside perception data.

[0124] The system's operations management module has the capability to manage roadside sensing equipment on its assigned highways and vehicles providing external data services. It can present equipment status, vehicle information, and event information to operations personnel in a visual manner. The assigned highways refer to the specific highway sections managed by the operations management module. Roadside sensing equipment management refers to the registration, configuration, status monitoring, and fault handling of the equipment. Vehicles providing external data services refer to connected vehicles subscribed to the system's early warning services. Service vehicles refer to vehicles currently receiving the system's early warning services.

[0125] This embodiment defines the hierarchical structure and dependencies between subsystems based on a module definition diagram, and defines the ports, interface protocols, and message channels between subsystems based on an internal module diagram, thus obtaining a technical solution for the logical architecture model. This solves the technical problems of unclear hierarchical structure, difficulty in tracing dependencies, lack of standardized definitions for ports and interface protocols, and difficulty in unified management of message channels among vehicle, road, and cloud subsystems, which lead to difficulties in system integration. It realizes structured modeling of the interconnection architecture between subsystems and provides a clear foundation for the interconnection relationship for parameter configuration in the physical architecture.

[0126] In step S104, based on the functional requirements of each subsystem in the interconnection architecture, the parameters that need to be configured in each subsystem are determined, and at least one constraint model diagram is generated. Based on the constraint model diagram, the constraint relationship between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model.

[0127] The interconnection architecture in this embodiment includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between the subsystems. The functional requirements of each subsystem refer to the responsibilities and tasks that each subsystem needs to undertake in the interconnection architecture. For example, the vehicle-side subsystem is responsible for data reporting and early warning reception, the roadside subsystem is responsible for environmental perception and data uploading, and the cloud platform subsystem is responsible for data fusion and decision calculation.

[0128] Based on the functional requirements of each subsystem in the interconnected architecture, the parameters that need to be configured in each subsystem are determined, and at least one constraint model diagram is generated. Here, parameters refer to adjustable variables that affect the behavior or performance of a subsystem, and constraint model diagrams are graphical models using system modeling languages ​​to describe the constraint relationships and computational logic between parameters, including parameter diagrams. Constraint relationships between different parameters within the same subsystem are defined based on the constraint model diagrams. These constraints refer to the rules governing mutual constraints or dependencies between multiple parameters within the same subsystem; for example, there is a design constraint relationship between the maximum warning latency constraint parameter and the data packet loss tolerance threshold parameter within the cloud platform subsystem. Simultaneously, the computational logic between parameters of different subsystems is defined based on the constraint model diagrams. This computational logic refers to the process of calculating parameters from different subsystems according to specific formulas or rules, such as calculating collision time using vehicle-side parameters and roadside parameters. Finally, a physical architecture model is obtained based on the defined constraint relationships and computational logic. The physical architecture model is an architectural view describing the physical implementation details of the system, which may include hardware configuration, parameter settings, and deployment schemes.

[0129] In one implementation, the constraint model diagram is a parametric diagram, and the subsystem includes a vehicle terminal system, a roadside subsystem, and a cloud platform subsystem. The parameters of the vehicle terminal system include the vehicle speed parameters and the speed parameters of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters. Based on the constraint model diagram, the constraint relationships between different parameters within the same subsystem and the computational logic between parameters of different subsystems are defined, resulting in the physical architecture model, including: Based on the parameter diagram, the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model.

[0130] In this embodiment, the constraint model diagram is a parametric diagram, a specialized diagram used to describe the constraint relationships and computational logic between parameters. The subsystem includes a vehicle-side subsystem, a roadside subsystem, and a cloud platform subsystem. The parameters of the vehicle-side subsystem include the vehicle's speed parameters and the speed of the vehicle in front. The vehicle's speed parameter refers to the instantaneous speed of the vehicle equipped with the warning system at the current moment, and the speed of the vehicle in front refers to the instantaneous speed of the adjacent vehicle traveling in the same lane ahead of the vehicle at the current moment. The parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing equipment, which refer to the actual spatial distance between the vehicle and the vehicle in front as measured by the roadside sensing equipment. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameter and the data packet loss tolerance threshold parameter. The maximum warning delay constraint parameter refers to the maximum allowable time delay from the occurrence of a risk to the delivery of the warning information to the vehicle, and the data packet loss tolerance threshold parameter refers to the maximum acceptable data loss ratio of the system.

[0131] Specifically, the constraint relationships between different parameters within the same subsystem are defined based on the parameter diagram. In the parameter diagram, the vehicle speed parameter and the preceding vehicle speed parameter within the vehicle-to-subsystem subsystem can be represented as parameter nodes. There is no direct constraint relationship between the two parameter nodes; they are collected independently. The maximum warning delay constraint parameter and the data loss tolerance threshold parameter within the cloud platform subsystem are represented as parameter nodes. There is a design constraint relationship between the two parameter nodes. For example, when the data loss tolerance threshold parameter is set high, it may be necessary to tighten the maximum warning delay constraint parameter to ensure warning reliability.

[0132] Next, the computational logic between parameters of different subsystems is defined based on the parameter diagram. In the parameter diagram, the vehicle speed parameters and preceding vehicle speed parameters of the vehicle-to-subsystem subsystem, and the relative distance parameters of the roadside subsystem are represented as parameter nodes, which are then connected by computational logic. The computational logic is expressed in mathematical formulas; for example, the formula for calculating collision time is relative distance divided by relative speed, where the relative speed equals the preceding vehicle speed minus the vehicle speed, or the vehicle speed minus the preceding vehicle speed depends on the relative speeds of the two vehicles. The parameter diagram connects input parameter nodes to output parameter nodes through constraint expressions, expressing the operational relationships between parameters. Finally, based on all the constraint relationships and computational logic defined in the parameter diagram, the physical architecture model is obtained.

[0133] In the specific implementation, the entity class parameters of the subsystem are first defined and configured. Entity class parameters refer to configurable variables related to physical devices or specific hardware, such as sensor sampling frequency, communication port number, and buffer size. Next, the information space algorithm module is decomposed and its interface is defined. The information space algorithm module refers to the software algorithm unit running on the computing platform, such as data fusion algorithm, risk identification algorithm, and early warning judgment algorithm. Decomposition refers to breaking down the information space algorithm module into smaller sub-modules or function units, and interface definition refers to clarifying the calling methods, input parameters, and output results provided by the information space algorithm module. Next, the algorithm code framework is built. The algorithm code framework refers to the program structure template of the algorithm module, including class definitions, function declarations, and basic logical skeleton.

[0134] Furthermore, by establishing a parameter diagram, the performance, cost, reliability, and other indicators of different architecture configuration schemes are compared, analyzed, and the best option is selected. Different architecture configuration schemes refer to multiple design alternatives formed by using different combinations of parameter values ​​for the same system. When the configuration scheme meets the preset requirements in terms of performance, cost, reliability, and other indicators, a physical architecture model that meets the conditions is obtained.

[0135] The following explanation uses high real-time collision warning as an example. High real-time collision warning refers to a warning service that provides a millisecond-level response to rear-end collision risks. By refining the functions, the parameters related to the warning are broken down and defined, including vehicle driving status, roadside perception data, and decision suggestions. Vehicle driving status refers to the vehicle's current motion attributes, which may include speed, acceleration, and heading angle; roadside perception data refers to environmental information collected by roadside equipment, which may include vehicle position, lane markings, and obstacles; decision suggestions refer to the guidance information output by the system based on the risk analysis results, which may include suggested speed and steering recommendations.

[0136] Next, the decomposed parameters are defined, including design constraints and performance parameters. Design constraints refer to the limitations that must be followed during system design, such as processor computing power limitations and communication bandwidth limitations. Performance parameters are quantitative indicators that measure the system's performance level, such as warning accuracy and warning latency. Then, these parameters are configured, which means assigning specific values ​​or value ranges to each parameter. Through parameter definition and configuration, executable code capable of covering all processing logic for a specific type of warning scenario is generated. (Refer to...) Figure 8 This diagram illustrates the definition of a high-real-time collision warning module in a method for constructing a high-speed early warning system according to an embodiment of the present invention. The high-real-time collision warning module is divided into two main parts: a collision warning module and a vehicle driving state module. The collision warning module defines the output parameters related to the warning decision, while the vehicle driving state module defines the input parameters related to the vehicle's operating state and their constraints.

[0137] The collision warning module includes four parameters: acceleration recommendation parameter, warning type parameter, collision distance parameter, and vehicle speed recommendation parameter. The acceleration recommendation parameter refers to the longitudinal acceleration value recommended by the system to the driver or the vehicle's autonomous driving system to avoid or mitigate a collision. The warning type parameter refers to the risk category identified by the system, including types such as forward collision warning, emergency braking warning, and lane change collision warning. The collision distance parameter is the remaining distance predicted by the system when a collision may occur between the vehicle and the vehicle in front. The vehicle speed recommendation parameter is the safe driving speed value recommended by the system to the driver or the vehicle's autonomous driving system.

[0138] There is a constraint relationship between the vehicle driving status module and the collision warning module, indicated by dashed arrows with constraint markers. This constraint relationship shows that the collision warning calculation depends on the vehicle driving status and roadside perception data. Specifically, the vehicle's own motion parameters provided by the vehicle driving status module and the environmental parameters collected by the roadside perception equipment are used as inputs, and after calculation by the collision warning algorithm, various warning parameters are output in the collision warning module.

[0139] The right side of the diagram illustrates the specific data structure definition of the parameters. The parameter definition block lists five parameters and their data types. The timestamp parameter is a real number and records the time point of parameter sampling. The target position parameter is a real number and represents the target vehicle's position coordinates in the road coordinate system. The target acceleration parameter is a real number and represents the target vehicle's acceleration value at the current moment. The target type parameter is a real number and identifies the category of the target object, such as cars, trucks, buses, motorcycles, etc. The target speed parameter is a real number and represents the target vehicle's instantaneous speed value at the current moment.

[0140] The parameter definition block and the collision warning module are connected by constraints, indicating that the parameters used in the collision warning module conform to the data structure and type specifications defined in the parameter definition block. The timestamp parameter, target position parameter, target acceleration parameter, target type parameter, and target velocity parameter together constitute the input data specifications required by the collision warning algorithm.

[0141] The module definition diagram clarifies the input parameter structure, output parameter composition, and computational dependencies between the input and output of the high real-time collision warning module through a graphical representation of parameter definitions and constraint relationships.

[0142] Reference Figure 9 The diagram illustrates the high-real-time collision warning decision suggestion parameters of the construction method of the high-speed early warning system according to an embodiment of the present invention, and shows the constraint relationship and calculation logic between the parameter nodes in the high-real-time collision warning decision process.

[0143] The high real-time collision warning decision suggestion parameter diagram contains six core parameter nodes: vehicle driving status parameter node, collision warning calculation parameter node, collision distance parameter node, alarm type parameter node, vehicle speed suggestion parameter node, and acceleration suggestion parameter node.

[0144] The vehicle driving state parameter node defines six parameter attributes required for the vehicle's own operating state, including timestamp, vehicle position, vehicle gear, vehicle speed, vehicle acceleration, and vehicle heading angle. The timestamp attribute records the sampling time of the vehicle state data and is a real number. The vehicle position attribute describes the vehicle's spatial coordinates in the road coordinate system and is a real number. The vehicle gear attribute identifies the vehicle's current gear position, including drive, reverse, and neutral, and is a real number. The vehicle speed attribute represents the vehicle's instantaneous speed and is a real number. The vehicle acceleration attribute represents the vehicle's instantaneous acceleration value and is a real number. The vehicle heading angle attribute represents the vehicle's direction of travel angle and is a real number.

[0145] The collision warning calculation parameter node defines five parameter attributes required by the collision warning algorithm, including timestamp, target location, vehicle speed, vehicle acceleration, and vehicle type. The target location attribute represents the spatial coordinates of the target vehicle in the road coordinate system, and is a real-valued numeric type. The vehicle type attribute represents the category of the target vehicle, including types such as cars, trucks, buses, and motorcycles, and is also a real-valued numeric type.

[0146] The collision distance parameter node defines five parameter attributes: timestamp, target position, vehicle speed, vehicle acceleration, and vehicle heading angle. Collision distance refers to the remaining distance predicted by the system when a collision may occur between the current vehicle and the vehicle in front.

[0147] The alarm type parameter node defines a parameter attribute, namely the timestamp attribute. The alarm type refers to the risk category identified by the system, including types such as forward collision warning, emergency braking warning, and lane change collision warning.

[0148] The vehicle speed suggestion parameter node defines a parameter attribute, namely the timestamp attribute. Vehicle speed suggestion refers to the safe driving speed value recommended by the system to the driver or the vehicle's autonomous driving system.

[0149] The acceleration recommendation parameter node defines a parameter attribute, namely the timestamp attribute. Acceleration recommendation refers to the longitudinal acceleration value recommended by the system to the driver or the vehicle's autonomous driving system to avoid or mitigate collisions.

[0150] The parameter nodes are connected by constraint expressions, forming a complete computational logic chain. The vehicle driving state parameter node serves as an input source, providing the vehicle's own motion state data to the collision warning calculation parameter node and the collision distance parameter node. The collision warning calculation parameter node receives vehicle speed and acceleration data from the vehicle driving state parameter node, and also receives externally input target position and target type data, executing a collision risk identification algorithm. The collision distance parameter node receives vehicle speed, vehicle acceleration, and vehicle heading angle data from the vehicle driving state parameter node, and also receives externally input target position data, executing a collision distance prediction algorithm.

[0151] The output of the collision warning calculation parameter node is passed to the alarm type parameter node to determine the type of alarm to be issued. The output of the collision distance parameter node is passed to the vehicle speed suggestion parameter node and the acceleration suggestion parameter node to determine the recommended safe vehicle speed and the recommended acceleration adjustment value. The outputs of the alarm type parameter node, the vehicle speed suggestion parameter node, and the acceleration suggestion parameter node together constitute the final result of the high real-time collision warning decision recommendation.

[0152] This parameter graph, through the graphical organization of parameter nodes and constraint expressions, clearly defines the complete computational logic from vehicle driving state input to collision warning decision suggestion output.

[0153] The parameter definitions and configurations in this embodiment facilitate subsequent evaluation of the parameter system through simulation, thereby assessing the system design. The parameter system refers to the overall structure of the set of all parameters in the system and their interrelationships; the evaluation result is the conclusion regarding whether the parameter system meets the design requirements.

[0154] For example, parameters can be defined for modules such as collision time calculation, risk level determination, and early warning strategy selection. Vehicle driving status, roadside perception data, and decision recommendations are considered entity parameters. The constraints and calculation logic between parameters are defined through a parameter graph, such as collision time calculation based on vehicle speed, relative distance, and roadside perception. Design constraints and performance parameters are defined, such as a maximum early warning delay of less than or equal to 100 milliseconds and a data loss tolerance threshold, forming a configurable technical model. A configurable technical model refers to a model structure whose parameter values ​​can be flexibly adjusted according to the application scenario without modifying the model's logic.

[0155] This embodiment defines the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems based on a parameter diagram. The parameters of the vehicle-to-vehicle subsystem include the vehicle's speed and the speed of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters. Based on the parameter diagram, a technical solution for obtaining the physical architecture model is provided. This solution solves the technical problems of lack of unified constraints on parameter configuration and unclear calculation logic between parameters of different subsystems in highway early warning systems, which makes it difficult to quantify and verify system performance. It realizes the visual definition of the constraint relationships and calculation logic between parameters, and provides a clear quantitative verification basis for subsequent simulation tests.

[0156] In step S105, the requirement model, functional architecture model, logical architecture model, and physical architecture model are output as model files, and simulation tests are performed on the model files. The simulation test results are compared with the constraint relationships defined in the constraint model diagram. If the comparison passes, the architecture scheme of the high-speed early warning system is output.

[0157] A model file is a computer file that carries system modeling language model data and is used to exchange model information between different tools. Simulation testing refers to the verification activity of running the model in a computer simulation environment and observing its behavioral response.

[0158] In this embodiment, the constraint model diagram is a parametric diagram. The constraint relationships include the constraints between different parameters within the same subsystem and the computational logic between parameters of different subsystems. If the simulation test results fully satisfy all the constraint relationships and computational logic defined in the constraint model diagram, the architecture scheme of the high-speed early warning system is output. The architecture scheme is a complete set of requirement models, functional architecture models, logical architecture models, and physical architecture models that have been verified and confirmed to meet the design requirements.

[0159] In one implementation, simulation testing of the model file includes: The model file is simulated and tested in at least one simulation scenario, including ramp merging scenario, sudden accident scenario, sensor failure scenario, network jitter scenario, and communication interruption scenario.

[0160] A simulation scenario refers to a set of virtual traffic environment conditions used to test the system, which may include elements such as road conditions, traffic status, vehicle behavior, and communication status. In this embodiment, the simulation scenarios may include ramp merging scenarios, sudden accident scenarios, sensor failure scenarios, network jitter scenarios, and communication interruption scenarios. Specifically, the ramp merging scenario simulates the traffic situation of vehicles entering the main road of a highway from a ramp, used to test the system's early warning capability in merging conflict situations; the sudden accident scenario simulates a traffic accident occurring suddenly ahead of the highway, used to test the system's rapid response capability in emergency situations; the sensor failure scenario simulates the failure of roadside sensing equipment or vehicle-mounted sensors, used to test the system's degradation processing capability when partial sensing capabilities are lost; the network jitter scenario simulates unstable communication network latency, used to test the system's robustness to communication quality fluctuations; and the communication interruption scenario simulates a complete disconnection of the communication link between the vehicle and the cloud, used to test the system's local autonomous decision-making capability when cloud support is lost.

[0161] This embodiment solves the technical problem that traditional system designs struggle to verify the architecture's behavior under complex and extreme scenarios in the early stages, leading to high costs for later defect discovery and repair. It enables full verification of the high-speed early warning system's operational behavior under various typical operating conditions and extreme conditions during the design phase, improving the system's reliability and robustness, and reducing later repair costs.

[0162] In one implementation, the method further includes: If the comparison fails, at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model shall be modified, and the simulation test shall be re-executed until the simulation test results satisfy the constraints.

[0163] In this embodiment, a failed comparison means that one or more indicators in the simulation test results do not meet the constraints defined in the constraint model diagram. When a comparison fails, the parts of the model that do not meet the constraints can be adjusted, including modifying the requirement definition, adjusting the functional decomposition, changing the interconnect architecture, or reconfiguring parameters. Then, the modified model is output as a model file again and simulation tests are performed. The above modification and testing process is repeated until all simulation test results meet the constraints defined in the constraint model diagram.

[0164] In practical implementation, an architecture definition system modeling language model is used to generate an algorithm framework. The system modeling language model refers to the collective term for the requirement model, functional architecture model, logical architecture model, and physical architecture model described using a system modeling language. The algorithm framework refers to the program code skeleton automatically generated from the system modeling language model, including function definitions, interface declarations, and basic logical structures.

[0165] Next, simulation verification is performed based on the code architecture of simulation tools such as Simulink. Simulink is a model-based simulation tool that supports modeling and simulation of multi-domain systems. Code architecture refers to the program structure specifications that the simulation tool can recognize and execute. The system modeling language model is imported into the simulation tool, and after generating executable code, compiling, and deploying, model-based simulation testing is conducted. Generating executable code means the simulation tool converts the model into executable program code; compilation means converting the generated executable code into machine instructions; and deployment means loading the compiled program into the simulation runtime environment.

[0166] Multiple test scenarios are constructed in the simulation environment. The simulation environment refers to the virtual operating platform provided by the simulation tool. Typical scenarios include ramp merging scenario, sudden accident scenario and communication interruption scenario. Extreme scenarios include sensor failure scenario and network jitter scenario.

[0167] During simulation testing, key technical indicators are collected to obtain simulation results. These key technical indicators may include early warning latency, decision consistency, and system response time. Early warning latency refers to the time from the occurrence of a risk event to the issuance of an early warning message to the vehicle; decision consistency refers to the degree of agreement between the judgments made by multiple decision modules or at different times regarding the same situation; and system response time refers to the time from receiving input to generating output.

[0168] The simulation results are compared with the constraints defined in the constraint model diagram to verify whether the architecture design satisfies all the constraints and computational logic defined in the constraint model diagram. If not, a cyclical process of repeatedly executing simulation tests and modifying the model is performed until all constraints are satisfied.

[0169] This embodiment solves the technical problem in traditional system design where, if the comparison fails, at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model is modified, and the simulation test is re-executed until the simulation test results satisfy the constraints. This solution addresses the limitations of optimization and improvement space and the difficulty in forming a design closed loop after discovering defects in traditional system design. It realizes a closed-loop iterative mechanism for architecture design from modeling, simulation to verification and optimization, ensuring that the final output architecture solution meets the preset constraints and improving the reliability and completeness of the system design.

[0170] Reference Figure 10 The diagram illustrates the model simulation verification flowchart of the construction method of the high-speed early warning system according to an embodiment of the present invention, demonstrating the complete closed-loop process from model to simulation verification to design optimization.

[0171] The term "model" refers to the collective name for the requirement model constructed in step S101, the functional architecture model constructed in step S102, the logical architecture model constructed in step S103, and the physical architecture model constructed in step S104. These models are described using a system modeling language and contain the requirement information, functional behavior, interconnection architecture, and parameter constraints of the high-speed early warning system.

[0172] Code generation refers to the process of converting a system modeling language model into executable program code. Simulation tools automatically generate algorithm framework code based on the activity diagrams, sequence diagrams, module definition diagrams, internal module diagrams, and parameter diagrams in the model. The code output from the code generation step is based on the model definition, and the data structures, function interfaces, and control logic in the code are consistent with the definitions in the model.

[0173] After the code is generated, compilation begins. Compilation is the process of converting the generated executable program code into machine-readable binary instructions. The compilation step transforms the high-level language code into a file format executable by the target platform, preparing it for subsequent deployment.

[0174] After compilation, the next step is deployment. Deployment refers to the process of loading the compiled executable file into the simulation runtime environment. The deployment steps involve deploying the code to the corresponding simulation nodes according to the needs of the simulation scenario, including vehicle-side simulation nodes, roadside simulation nodes, and cloud platform simulation nodes.

[0175] After deployment, testing begins. Testing involves executing the deployed executable code in a simulation environment and observing the system's behavior. Testing is conducted in various simulation scenarios, including ramp merging, sudden accident scenarios, sensor failure scenarios, network jitter scenarios, and communication interruption scenarios. Key technical indicators are collected during testing, including warning latency, decision consistency, and system response time.

[0176] After testing, the process moves to design optimization, which involves adjusting and improving the model based on the simulation test results collected during the testing phase. The simulation test results are compared with the constraints defined in the constraint model diagram. If the comparison fails, at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model is modified. The modified model output from the design optimization phase re-enters the process starting point and undergoes code generation, compilation, deployment, and testing steps for verification.

[0177] If the simulation test results satisfy the constraint relationships defined in the constraint model diagram, the comparison passes, and the architecture scheme of the high-speed early warning system is output. The architecture scheme is a complete set of requirement models, functional architecture models, logical architecture models, and physical architecture models that have been verified and confirmed to meet the design requirements.

[0178] The simulation tools used in simulation testing generally refer to software platforms that support model import, code generation, compilation, deployment, and testing, such as Simulink. After the model is completed in the modeling tool, it is imported into the simulation tool. The simulation tool then performs the code generation, compilation, deployment, and testing steps, and feeds the test results back to the design optimization step.

[0179] This flowchart demonstrates the simulation verification closed loop of the model-based high-speed early warning system architecture construction method through a serial process from model to code generation, compilation, deployment, and testing, as well as a feedback loop from testing to design optimization and back to the model.

[0180] This embodiment also provides a construction apparatus for a high-speed early warning system, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0181] This embodiment provides a device for constructing a high-speed early warning system, such as... Figure 12 As shown, it includes: The requirement model construction module 1201 is used to obtain the system requirements of the high-speed early warning system to be constructed, generate at least one requirement model diagram based on the system requirements, and construct a requirement model based on the requirement model diagram. The high-speed early warning system includes at least one subsystem.

[0182] The functional architecture model construction module 1202 is used to decompose the top-level functions of the high-speed early warning system according to the system requirements, obtain at least one behavior model diagram, define the interaction sequence between each subsystem according to the behavior model diagram, and obtain the functional architecture model.

[0183] The logical architecture model construction module 1203 is used to extract the data flow and control flow between subsystems based on the interaction sequence defined in the behavioral model diagram, generate at least one structural model diagram based on the data flow and control flow, define the interconnection architecture between subsystems based on the structural model diagram, and obtain the logical architecture model.

[0184] The physical architecture model construction module 1204 is used to determine the parameters that need to be configured in each subsystem based on the functional requirements of each subsystem in the interconnection architecture, and generate at least one constraint model diagram. Based on the constraint model diagram, the constraint relationship between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model.

[0185] The architecture output module 1205 is used to output the requirement model, functional architecture model, logical architecture model and physical architecture model as model files, perform simulation tests on the model files, and compare the simulation test results with the constraint relationships defined in the constraint model diagram. If the comparison is successful, the architecture scheme of the high-speed early warning system is output.

[0186] In some optional implementations, the requirement model diagram includes a requirement analysis diagram and a use case diagram, and the requirement model construction module 1201 includes: The capability set partitioning unit is used to extract the requirement information from the system requirements and divide the requirement information into a top-level capability set and a sub-capability set corresponding to each top-level capability set according to the preset requirement dimensions.

[0187] The requirement model building unit is used to generate a requirement analysis diagram based on the hierarchical relationship between various requirement information, and to generate a use case diagram based on the correlation between various requirement information, and to build a requirement model based on the requirement analysis diagram and the use case diagram.

[0188] In some alternative implementations, the functional architecture model building module 1202 includes: The functional decomposition unit is used to decompose the high-speed early warning system layer by layer according to the system requirements, from the overall system to the subsystem, from the subsystem to the functional module, and from the functional module to the sub-function, so as to obtain at least one system function of the high-speed early warning system.

[0189] The behavior model diagram generation unit is used to determine logical elements according to the business process of the high-speed early warning system, and generate at least one behavior model diagram based on system functions, logical elements, and the execution order between system functions.

[0190] In some optional implementations, the behavioral model diagram includes activity diagrams and sequence diagrams, and the functional architecture model building module 1202 further includes: The execution flow determination unit is used to determine the execution flow of each functional module of the high-speed early warning system to be built under the preset early warning scenario based on the activity diagram. The execution flow includes data flow and control flow.

[0191] The functional architecture model building unit is used to define the interaction sequence between subsystems based on the sequence diagram, and to obtain the functional architecture model according to the execution flow and interaction sequence. The interaction sequence includes message format, triggering conditions and timeout handling mechanism.

[0192] In some optional implementations, the structural model diagram includes a module definition diagram and an internal module diagram, and the interconnection architecture includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between subsystems; the logical architecture model construction module 1203 includes: The logical architecture model building unit is used to define the hierarchical structure and dependencies between subsystems based on the module definition diagram, and to define the ports, interface protocols and message channels between subsystems based on the internal module diagram, thus obtaining the logical architecture model.

[0193] In some optional implementations, the constraint model diagram is a parametric diagram, and the subsystem includes a vehicle-to-vehicle (V2V) subsystem, a roadside subsystem, and a cloud platform subsystem. The parameters of the V2V subsystem include the vehicle's speed parameters and the speed of the vehicle in front; the parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing devices; and the parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters. The physical architecture model construction module 1204 includes: The physical architecture model building unit is used to define the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems based on the parameter diagram, so as to obtain the physical architecture model.

[0194] In some alternative implementations, the architecture output module 1205 includes: The simulation test unit is used to perform simulation tests on the model file under at least one simulation scenario, including ramp merging scenario, sudden accident scenario, sensor failure scenario, network jitter scenario, and communication interruption scenario.

[0195] In some alternative embodiments, the apparatus further includes: The optimization module is used to modify at least one of the requirement model, functional architecture model, logical architecture model, and physical architecture model if the comparison fails, and to re-execute the simulation test until the simulation test results meet the constraints.

[0196] The apparatus for constructing a high-speed early warning system provided in this embodiment of the invention can execute the method for constructing a high-speed early warning system provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0197] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0198] The following is a detailed reference. Figure 13The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 1301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (i.e., ROM 1302) or a program loaded from memory 1308 into a random access memory (i.e., RAM 1303). The RAM 1303 also stores various programs and data required for the operation of the electronic device. The processor 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. Input / output (i.e., I / O interface 1305) is also connected to the bus 1304.

[0199] Typically, the following devices can be connected to I / O interface 1305: input devices 1306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1309. Communication device 1309 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 13 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0200] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1309, or installed from a memory 1308, or installed from a ROM 1302. When the computer program is executed by the processor 1301, it performs the functions defined in the method for constructing a high-speed early warning system according to embodiments of the present invention.

[0201] Figure 13 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0202] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the method for constructing the high-speed early warning system shown in the above embodiments is implemented.

[0203] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0204] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for constructing a high-speed early warning system, characterized in that, The method includes: Obtain the system requirements of the high-speed early warning system to be constructed, generate at least one requirement model diagram based on the system requirements, construct a requirement model based on the requirement model diagram, and the high-speed early warning system includes at least one subsystem; Based on the system requirements, the top-level functions of the high-speed early warning system are decomposed to obtain at least one behavioral model diagram. Based on the behavioral model diagram, the interaction sequence between each subsystem is defined to obtain a functional architecture model. Based on the interaction sequence defined in the behavior model diagram, the data flow and control flow between each subsystem are extracted, and at least one structural model diagram is generated according to the data flow and control flow. Based on the structural model diagram, the interconnection architecture between each subsystem is defined to obtain the logical architecture model. Based on the functional requirements of each subsystem in the interconnection architecture, the parameters that need to be configured in each subsystem are determined, and at least one constraint model diagram is generated. Based on the constraint model diagram, the constraint relationship between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model. The requirement model, the functional architecture model, the logical architecture model, and the physical architecture model are output as model files. The model files are then subjected to simulation tests. The simulation test results are compared with the constraint relationships defined in the constraint model diagram. If the comparison passes, the architecture scheme of the high-speed early warning system is output.

2. The method according to claim 1, characterized in that, The requirement model diagram includes a requirement analysis diagram and a use case diagram. The step of generating at least one requirement model diagram based on the system requirements and constructing a requirement model based on the requirement model diagram includes: Extract the requirement information from the system requirements, and divide the requirement information into a top-level capability set and a sub-capability set corresponding to each top-level capability set according to a preset requirement dimension; A requirement analysis diagram is generated based on the hierarchical relationship between the various requirement information, and a use case diagram is generated based on the correlation between the various requirement information. The requirement model is then constructed based on the requirement analysis diagram and the use case diagram.

3. The method according to claim 2, characterized in that, The decomposition of the top-level functions of the high-speed early warning system based on the system requirements yields at least one behavioral model diagram, including: Based on the system requirements, the high-speed early warning system is decomposed layer by layer from the overall system to the subsystem, from the subsystem to the functional module, and from the functional module to the sub-function, to obtain at least one system function of the high-speed early warning system; Logical elements are determined according to the business process of the high-speed early warning system, and at least one behavioral model diagram is generated based on the system functions, the logical elements, and the execution order between the system functions.

4. The method according to claim 1, characterized in that, The behavioral model diagram includes activity diagrams and sequence diagrams. The functional architecture model is obtained by defining the interaction sequence between subsystems based on the behavioral model diagram, including: Based on the activity diagram, the execution flow of each functional module of the high-speed early warning system to be constructed under the preset early warning scenario is determined, and the execution flow includes data flow and control flow; The interaction sequence between each subsystem is defined based on the sequence diagram, and the functional architecture model is obtained according to the execution flow and the interaction sequence. The interaction sequence includes message format, triggering conditions and timeout handling mechanism.

5. The method according to claim 1, characterized in that, The structural model diagram includes a module definition diagram and an internal module diagram. The interconnection architecture includes at least the hierarchical structure, dependencies, ports, interface protocols, and message channels between the subsystems. The logical architecture model is obtained by defining the interconnection architecture between the subsystems based on the structural model diagram, including: Based on the module definition diagram, the hierarchical structure and dependencies between subsystems are defined, and based on the internal module diagram, the ports, interface protocols, and message channels between subsystems are defined, thus obtaining the logical architecture model.

6. The method according to claim 1, characterized in that, The constraint model diagram is a parametric diagram. The subsystem includes a vehicle terminal system, a roadside subsystem, and a cloud platform subsystem. The parameters of the vehicle terminal system include the vehicle speed parameters and the speed parameters of the vehicle in front. The parameters of the roadside subsystem include the relative distance parameters collected by the roadside sensing devices. The parameters of the cloud platform subsystem include the maximum warning delay constraint parameters and the data packet loss tolerance threshold parameters. The constraint model diagram defines the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems, resulting in a physical architecture model, including: Based on the parameter diagram, the constraint relationships between different parameters within the same subsystem and the calculation logic between parameters of different subsystems are defined to obtain the physical architecture model.

7. The method according to claim 1, characterized in that, The simulation test of the model file includes: The model file is simulated and tested in at least one simulation scenario, including a ramp merging scenario, a sudden accident scenario, a sensor failure scenario, a network jitter scenario, and a communication interruption scenario.

8. The method according to claim 1, characterized in that, The method further includes: If the comparison fails, at least one of the requirement model, the functional architecture model, the logical architecture model, and the physical architecture model shall be modified, and the simulation test shall be re-executed until the simulation test results satisfy the constraints.

9. An electronic device, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the method for constructing a high-speed early warning system as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the method for constructing a high-speed early warning system according to any one of claims 1 to 8.

Images