Architecture design method, device and related equipment of intelligent automobile cyber physical system

Abstract

The application discloses an architecture design method and device of an intelligent automobile cyber-physical system and related equipment. It relates to the technical field of vehicles and road traffic. The method comprises the following steps: obtaining the architecture design requirements of the intelligent automobile cyber-physical system; in response to the architecture design requirements, constructing the view architecture of each perspective according to the metamodel of each view in the preset system architecture framework under multiple perspectives, and obtaining the initial architecture model of the intelligent automobile cyber-physical system; and simulating and optimizing the initial architecture model to obtain the target architecture model of the intelligent automobile cyber-physical system. According to the embodiment of the application, the design path and output standard are specified by a unified architecture framework, the design language and understanding, design boundary and analysis granularity of multiple participants are unified, and the design consensus of multiple stakeholders is reached.

Description

Technical Field

[0001] This application belongs to the field of vehicle and road traffic technology, and in particular relates to an architecture design method, device and related equipment for an intelligent vehicle cyber-physical system. Background Technology

[0002] The Intelligent Vehicle Cyber-Physical System (IVCPS) is a system in which intelligent vehicles and intelligent roadside systems achieve cross-system interconnection through communication networks, and realize cross-system collaborative perception, collaborative decision-making, and collaborative control based on a cloud control platform. In real-world traffic environments, the IVCPS forms a cohesive whole with deep multi-entity interaction, resource sharing, and capability integration, aiming to achieve system-level perception, system-level decision-making, and system-level control, thereby improving the overall safety, efficiency, and service level of traffic.

[0003] However, in the current IVCPS architecture design, due to the different understandings of various stakeholders (such as OEMs, suppliers, traffic management departments, and technology companies) in their designs, the design objects are unclear and their boundaries and granularity are inconsistent, making it difficult to reach a domain-specific consensus. Furthermore, the resulting architectural solutions suffer from poor readability, disorganized layers, and logical breaks, leading to weak traceability between requirements, design, and implementation. This results in requirements not being accurately implemented, and design content is prone to duplication, contradictions, or key omissions. Ultimately, this significantly increases the risk of project rework and integration failures, drives up development costs and timelines, and severely restricts the implementation of advanced system capabilities. Summary of the Invention

[0004] This application provides an architecture design method, device, and related equipment for an intelligent vehicle cyber-physical system. It can standardize the design path and output standards through a unified architecture framework, unify the design language and understanding, design boundaries and analysis granularity of multiple stakeholders, and enable multiple stakeholders to reach a design consensus.

[0005] In a first aspect, embodiments of this application provide an architecture design method for an intelligent vehicle cyber-physical system, the method comprising: Obtain the architectural design requirements of the intelligent vehicle cyber-physical system; In response to the architecture design requirements, based on the meta-model of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system. The initial architecture model is simulated and optimized to obtain the target architecture model of the intelligent vehicle cyber-physical system.

[0006] Secondly, embodiments of this application provide an architecture design device for an intelligent vehicle cyber-physical system, the device comprising: The acquisition module is used to acquire the architectural design requirements of the intelligent vehicle cyber-physical system; The construction module is used to respond to the architecture design requirements and construct the view architecture of each view from a multi-dimensional perspective in the preset system architecture framework, so as to obtain the initial architecture model of the intelligent vehicle cyber-physical system. The simulation module is used to perform simulation optimization on the initial architecture model to obtain the target architecture model of the intelligent vehicle cyber-physical system.

[0007] Thirdly, embodiments of this application provide an electronic device, the device including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the architecture design method of the intelligent vehicle cyber-physical system as described above.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the architecture design method of the intelligent vehicle cyber-physical system as described above.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein when the instructions in the computer program product are executed by the processor of an electronic device, the electronic device performs the architecture design method of the intelligent vehicle cyber-physical system as described in any of the above claims.

[0010] The intelligent vehicle cyber-physical system (IVCPS) architecture design method, apparatus, and related equipment of this application embodiment can respond to the architecture design requirements of the IVCPS. Based on the meta-models of each view from multiple perspectives within a preset architecture framework, it constructs view architectures for each perspective, obtaining an initial architecture model of the IVCPS. The initial architecture model is then simulated and optimized to obtain the target architecture model of the IVCPS. Thus, by standardizing the design path and output standards through a unified architecture framework, this application embodiment unifies the design language and understanding, design boundaries, and analysis granularity among multiple stakeholders. This not only enables multiple stakeholders to reach a design consensus but also results in a clear and logically coherent architecture solution. Furthermore, through standardized architecture modeling and subsequent simulation optimization closed-loop, the entire architecture design process is made controllable, proactively avoiding design duplication, contradictions, and omissions, ensuring the traceability of requirements, design, and implementation, and ultimately significantly reducing the risk of project rework and integration failures, compressing development costs and timelines, and supporting the implementation of advanced IVCPS system capabilities. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the architecture design method of the intelligent vehicle cyber-physical system provided in the embodiments of this application; Figure 2 This is the IVCPS architecture framework mesh provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the relationship between the IVCPS architecture framework perspective-view-view metamodel and the architecture construction model provided in this application embodiment; Figure 4 This is a schematic diagram of the process for constructing the IVCPS architecture model provided in the embodiments of this application; Figure 5 This is a schematic diagram of the architecture design reference flow based on the IVCPS architecture framework provided in the embodiments of this application; Figure 6(1) is a schematic diagram of the operation of creating a new project provided in the embodiment of this application; Figure 6(2) is a schematic diagram of the operation of completing project creation provided in the embodiment of this application; Figure 6(3) is a schematic diagram of the operation of unfolding the IVCPS architecture model design work provided in the embodiment of this application; Figure 6(4) is a schematic diagram of the operation of constructing the design element module provided in the embodiment of this application; Figure 6(5) is a schematic diagram of the operation of simulating the architecture model provided in the embodiment of this application; Figure 7 This is a schematic diagram of the architecture design device for the intelligent vehicle cyber-physical system provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] The Intelligent Vehicle Cyber-Physical System (IVCPS) is a system in which intelligent vehicles and intelligent roadside systems achieve cross-system interconnection through communication networks, and realize cross-system collaborative perception, collaborative decision-making, and collaborative control based on a cloud control platform. In real-world traffic environments, the IVCPS forms a cohesive whole with deep multi-entity interaction, resource sharing, and capability integration, aiming to achieve system-level perception, system-level decision-making, and system-level control, thereby improving the overall safety, efficiency, and service level of traffic.

[0016] However, in the current IVCPS architecture design, due to the different understandings of various stakeholders (such as OEMs, suppliers, traffic management departments, and technology companies) in their designs, the design objects are unclear and their boundaries and granularity are inconsistent, making it difficult to reach a domain-specific consensus. Furthermore, the resulting architectural solutions suffer from poor readability, disorganized layers, and logical breaks, leading to weak traceability between requirements, design, and implementation. This results in requirements not being accurately implemented, and design content is prone to duplication, contradictions, or key omissions. Ultimately, this significantly increases the risk of project rework and integration failures, drives up development costs and timelines, and severely restricts the implementation of advanced system capabilities.

[0017] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0018] To address the problems of existing technologies, embodiments of this application provide an architecture design method, apparatus, and related equipment for an intelligent vehicle cyber-physical system. The architecture design method for the intelligent vehicle cyber-physical system provided in this application embodiment will be described first below.

[0019] Figure 1 This illustration shows a flowchart of an architecture design method for an intelligent vehicle cyber-physical system according to an embodiment of this application. Figure 1 As shown, an architecture design method for an intelligent vehicle cyber-physical system may include the following steps S101 to S103: S101. Obtain the architectural design requirements of the cyber-physical system of intelligent vehicles; S102. In response to the architecture design requirements, based on the meta-model of each view under the multi-dimensional perspective in the preset system architecture framework, construct the view architecture of each perspective to obtain the initial architecture model of the intelligent vehicle cyber-physical system. S103. Simulate and optimize the initial architecture model to obtain the target architecture model of the intelligent vehicle cyber-physical system.

[0020] The architecture design method for intelligent vehicle cyber-physical systems (IVCPS) in this application embodiment can respond to the architecture design requirements of IVCPS. Based on the meta-models of various views in a pre-defined architecture framework, it constructs view architectures for each viewpoint, obtaining an initial architecture model of the IVCPS. The initial architecture model is then simulated and optimized to obtain the target architecture model of the IVCPS. Thus, by standardizing the design path and output standards through a unified architecture framework, this application embodiment unifies the design language and understanding, design boundaries, and analysis granularity among multiple stakeholders. This not only enables multiple stakeholders to reach a design consensus but also results in a clear and logically coherent architecture solution. Furthermore, through standardized architecture modeling and subsequent simulation optimization loops, the entire architecture design process is made controllable, proactively avoiding design duplication, contradictions, and omissions, ensuring the traceability of requirements, design, and implementation. Ultimately, this significantly reduces the risk of project rework and integration failures, compresses development costs and timelines, and supports the implementation of advanced IVCPS capabilities.

[0021] In S101, the aforementioned architecture design requirements can refer to the set of all-dimensional inputs that drive the entire system architecture design. They are the benchmark requirements that clarify "what the IVCPS system should look like, what core objectives it should achieve, and what hard constraints it should meet." They are the starting point of the entire architecture design process and the core benchmark for ultimately verifying whether the architecture model is qualified.

[0022] In some embodiments of this application, obtaining the architecture design requirements of the intelligent vehicle cyber-physical system can, for example, be done in response to user input on the display interface, by receiving the architecture design requirements of the intelligent vehicle cyber-physical system.

[0023] In S102, the aforementioned system architecture framework may include multi-dimensional perspectives, at least one view from each perspective, and a meta-model corresponding to each view. These perspectives can correspond to the basic angles from which architecture designers observe and analyze the system, used to clearly analyze the hierarchical structure of the IVCPS system, thereby decoupling the capabilities of each level of the IVCPS system, defining the design scope, and guiding designers at what granularity their work should be. For example, multi-dimensional perspectives may include scenario and capability perspectives, operational perspectives, service perspectives, resource perspectives, security perspectives, standard perspectives, and verification perspectives.

[0024] The views described above can be used to further focus on specific aspects of concern to the architect (such as classification, structure, connection, process, etc.) from each given perspective. Each view needs to indicate to the designer which specific aspects of the object of concern should be analyzed and provide corresponding suggestions on the selection of architectural model diagram types.

[0025] The metamodel corresponding to the above views can abstract the core concepts contained in each view into design elements of the architecture model based on the definition of each view, and clearly define the relationships between these elements for model representation. This metamodel clarifies the element modules that should be included in an architecture model, providing standardized constructs for actual architecture model design, ensuring that the elements are complete and the relationships are clear during modeling, and avoiding design omissions and logical contradictions.

[0026] The initial architecture model of the aforementioned intelligent vehicle cyber-physical system can include a view architecture from the perspectives of scenarios and capabilities, operation, services, security, standards, and resources.

[0027] In S103, the target architecture model of the aforementioned intelligent vehicle cyber-physical system can be an architecture model of the intelligent vehicle cyber-physical system that meets the architecture design requirements.

[0028] In some embodiments of this application, the initial architecture model is simulated and optimized to obtain the target architecture model of the intelligent vehicle cyber-physical system. For example, the initial architecture model can be simulated using a preset simulation tool in the verification perspective to obtain the simulation results of the initial architecture model. The simulation results are used to characterize whether the initial architecture model meets the architecture design requirements. If the simulation results indicate that the initial architecture model meets the architecture design requirements, the initial architecture model is determined as the target architecture model of the intelligent vehicle cyber-physical system. If the simulation results indicate that the initial architecture model does not meet the architecture design requirements, the initial architecture model is optimized until the architecture design requirements are met, thereby obtaining the target architecture model of the intelligent vehicle cyber-physical system.

[0029] As one implementation of this application, in order to provide a unified system architecture framework, the method may further include the following before S102: Based on the architectural framework construction principle of intelligent vehicle cyber-physical system, a multi-dimensional perspective is defined, with different perspectives corresponding to different levels and angles of concern; Based on the concern level and angle corresponding to each perspective, define at least one view under each perspective. Different views are used to indicate different concerns and architectural model diagram selection suggestions. The concerns, design objects, relationships, and textual definitions of each view are modeled to obtain the metamodel corresponding to each view; The above-mentioned system architecture framework may include a multi-dimensional perspective, at least one view of each perspective, and a meta-model corresponding to each view.

[0030] The architectural framework construction principle of the aforementioned intelligent vehicle cyber-physical system can, for example, be based on the definition in "Software, Systems and Enterprise—Architecture Description" (ISO / IEC / IEEE 42010:2022): the perspective and view of the architectural framework should reflect "stakeholder concerns," providing stakeholders with a descriptive and analytical framework for complex organizational systems. Therefore, when designing the architectural framework perspective and view, it is necessary to first identify the stakeholders and their concerns related to the development and business processes at each stage, and then design the architectural framework perspective and view based on these stakeholder concerns to ensure that it meets the needs of stakeholder description.

[0031] The aforementioned multi-dimensional perspectives can include scenario and capability perspectives, operational perspectives, service perspectives, resource perspectives, security perspectives, standards perspectives, and verification perspectives. Different perspectives correspond to different concerns. Specifically, the scenario and capability perspective is the first horizontal perspective of the IVCPS architecture framework. Its task is to conduct a detailed analysis and explanation of the complex scenario functions contained within the IVCPS system's application scenarios from a top-level perspective. Under this perspective, developers focus on: "Why build an IVCPS system?", "How should the system respond to requirements?", and "What actual response capabilities does the system possess?"

[0032] The operational perspective is the second horizontal perspective of the IVCPS architecture framework. Its task is to design operational schemes that meet the core requirements of the application scenario and satisfy the characteristics of "multi-temporal and spatial scales," describing the interrelationships of the system's operational interactions at different temporal and spatial scales. From this perspective, developers are concerned with formulating feasible operational schemes under clearly defined application scenarios and tasks, allocating IVCPS system capabilities within the schemes (operational capabilities = execution entities + operational activities), and describing the operational behaviors, interactions, activity flows, states, timing, risks, constraints and standards, parameters and metrics of the IVCPS system at different temporal and spatial scales to support the requirements of higher-level capabilities. This involves identifying the elements and relationships involved and forming a meta-model. Finally, based on the above elements and information, the elements related to requirements analysis are analyzed and extracted, forming the architectural meta-model of the requirements analysis view from this perspective. This guides developers in identifying operational capability requirements and serves as input for the service and resource perspectives of architecture design.

[0033] The service perspective is the third horizontal perspective in the IVCPS architecture framework. Its task is to analyze and categorize multi-level system services (internal and external services, services and their sub-services) based on operational plans, laying the foundation for system-level and subsystem-level resource allocation for multiple cyber-physical heterogeneous entities. From this perspective, the core concern for developers is how to define services based on upper-level capability requirements (including operational activities, operational risks, and information security control strategies), that is, clarifying service requirements through multi-view analysis (the specific implementation of services is completed from the resource perspective). In the IVCPS system, "service" refers not only to software services but also to functional categories encompassed by system capabilities and requirements, such as communication, computing, protection, control, and sensing, as well as services provided by various platforms.

[0034] The resource perspective is the fourth horizontal perspective in the IVCPS architecture framework. Its task is to allocate functions and parameters to different resource entities, such as the various component systems and their internal subsystems within the IVCPS system, based on multi-level system services. This addresses the problems of complex interaction relationships, synchronization and system difficulties, and unclear function allocation caused by the "multiple cyber-physical heterogeneous entities" characteristic of previous IVCPS architecture designs. From this perspective, developers are concerned with developing a solution architecture for the IVCPS system based on the capability requirements input from other perspectives. This architecture consists of specific resources (such as the component systems and their subsystems, external known resources like the support platform, enabling resources, capability configurations, and software), supporting the implementation of capabilities at all levels and ultimately completing various tasks in the application scenario.

[0035] The security perspective is the vertical perspective within the IVCPS architecture framework, permeating the previous four horizontal perspectives. When designing an IVCPS system solution architecture for application scenarios and tasks, it is necessary not only to analyze the capability requirements of each layer but also to identify and assess the potential risks within that layer, thereby clarifying the requirements for addressing and controlling these risks. Based on the risk control requirements, risk control strategies are designed.

[0036] The standards perspective is the vertical perspective within the IVCPS architecture framework, permeating all perspectives. From this perspective, developers are concerned with identifying and tracing the legal regulations and standards that must be followed and referenced when designing and analyzing the IVCPS system at each level. Through a series of views, elements, and relationships, it provides standardized guidance for the design of capability architecture at each level, ensuring compliance with and traceability of relevant legal and standard requirements. Simultaneously, this perspective is also used to identify deficiencies in existing standards and propose the development needs of new standards.

[0037] The verification perspective is a horizontal perspective within the IVCPS architecture framework. Unlike the previous four horizontal perspectives, which focus on the relationships between architectural elements, this perspective focuses on the architecture that requires simulation testing, verification, analysis, and evaluation, as well as confirming the allocation and attribution of capabilities and responsibilities involved. It's important to note that this perspective provides a three-view architectural meta-model, aiming to provide developers with verification specifications to carry out related work (architectural modeling by view is not mandatory). This perspective guides developers to verify, evaluate, and optimize the correctness, rationality, and efficiency of the IVCPS solution architecture design results using simulation software, based on actual resource configuration parameters, to determine whether it meets requirements, weigh the differences between different solutions, and justify the selection criteria for the final solution.

[0038] The different views mentioned above can be used to indicate different areas of focus, analytical aspects, and architectural model diagram selection recommendations.

[0039] The views of at least one of the above-mentioned scenarios and capabilities may include a vision view of the intelligent vehicle cyber-physical system, a stakeholder needs view during the operation phase, an application scenario task analysis view, an application scenario environment analysis view, a standard classification view, a capability list view of the intelligent vehicle cyber-physical system, a capability status and effect analysis view, a measurement index parameter view, a scenario capability constraint view, a risk analysis parameter view, and a scenario and task development requirements view.

[0040] At least one of the above operational perspectives may include a classification view of the main operating entities of the intelligent vehicle cyber-physical system, an operational plan strategy view, a first operational process view, an operational port view, a second operational process view, a measurement index parameter view, a risk analysis parameter view, an operational architecture instance view, an operational traceability view, and a service development requirement view.

[0041] At least one of the above service perspectives may include a service classification view, a service structure analysis view, a first service process view, a service port view, a second service process view, a measurement indicator parameter view, a risk analysis parameter view, a service architecture instance view, a service traceability view, and a resource development requirement view.

[0042] At least one of the aforementioned security perspectives may include a risk and control motivation view, a cybersecurity classification view, a cybersecurity constraint view, and a cybersecurity traceability view. In some embodiments, a cybersecurity structure view may also be included.

[0043] At least one of the aforementioned standard perspectives may include a standard inventory view, a standard traceability view, and a standard requirements view. In some embodiments, a standard architecture view may also be included.

[0044] At least one of the above resource perspectives may include a cyber-physical classification view, a resource service structure view, a first resource process view, a cyber-physical resource port view, a measurement index parameter view, a cyber-physical resource status view, a second resource process view, a risk analysis parameter view, a cyber-physical resource architecture instance view, a cyber-physical traceability view, and a cyber-physical resource capability requirement view.

[0045] The view of at least one of the above verification perspectives may include a verification structure view, a verification connection view, and a verification traceability view.

[0046] In this embodiment, by defining multi-dimensional perspectives and views under each perspective through the principle of architectural framework construction, and abstracting the hierarchical construction logic of view metamodels, a three-layer standardized architectural design system of perspectives, views, and metamodels is formed. Thus, by pre-defining multi-dimensional perspectives adapted to the intelligent vehicle cyber-physical system, views under each perspective, and constructing corresponding metamodels, a dedicated system architecture framework is formed. This framework aligns with the characteristics of the IVCPS domain, overcoming the shortcomings of general architectural frameworks in terms of domain mismatch and guidance for abstraction. Simultaneously, the standardized metamodel unifies the boundaries, granularity, and analytical dimensions of the architectural design, avoiding hierarchical confusion, logical breaks, element duplication, or missing elements in the design. It provides a standardized and rigorous modeling basis for subsequent view architecture construction, further ensuring the consistency and traceability of the architectural design.

[0047] In some embodiments, the aforementioned multi-dimensional perspective may include scene and capability perspectives, and S102 may specifically include: In response to architectural design requirements, based on the meta-model of the vision view of the intelligent vehicle cyber-physical system from the perspective of scenarios and capabilities in the preset system architecture framework, an intelligent vehicle cyber-physical system vision view is constructed. The intelligent vehicle cyber-physical system vision view is used to obtain the vision for the construction of the intelligent vehicle cyber-physical system from the architectural design requirements. Based on the metamodel and vision of the stakeholder needs view in the operation phase from the perspective of scenarios and capabilities in the pre-set system architecture framework, the stakeholder needs view in the operation phase is constructed. The stakeholder needs view in the operation phase is used to obtain the needs of stakeholders in the system operation phase. Based on the meta-model of the application scenario task analysis view from the perspective of scenarios and capabilities in the pre-set system architecture framework, the application scenario task analysis view is constructed. The application scenario task analysis view is used to obtain the usage conditions and scope of the intelligent vehicle cyber-physical system capabilities of the application scenario, as well as the evaluation aspects and measurement indicators of the ability to realize the application scenario and tasks. Based on the meta-model of the application scenario environment analysis view from the perspective of scenarios and capabilities in the preset system architecture framework, an application scenario environment analysis view is constructed. The application scenario environment analysis view is used to obtain the scenario environment faced by the intelligent vehicle cyber-physical system. Based on the metamodel of the standard classification view from the perspective of scenarios and capabilities in the pre-set system architecture framework, a standard classification view is constructed. The standard classification view is used to obtain the standards and laws and regulations that the application scenario tasks need to follow. Based on the meta-model of the intelligent vehicle cyber-physical system capability list view from the perspective of scenarios and capabilities in the preset system architecture framework, an intelligent vehicle cyber-physical system capability list view is constructed. The intelligent vehicle cyber-physical system capability list view is used to define the capabilities of the intelligent vehicle cyber-physical system. Based on the meta-model of the capability status and effect analysis view from the perspective of scenario and capability in the preset system architecture framework, the capability status and effect analysis view is constructed. The capability status and effect analysis view is used to obtain the gap between the capabilities and requirements of the intelligent vehicle cyber-physical system. Based on the meta-model of the measurement index parameter view from the perspective of scenarios and capabilities in the preset system architecture framework, the measurement index parameter view is constructed and used for task parameter modeling. Based on the metamodel of the scenario capability constraint view from the perspective of scenarios and capabilities in the preset system architecture framework, a scenario capability constraint view is constructed. The scenario capability constraint view is used to obtain the constraints and limitations of the current level of capabilities. Based on the meta-model of the risk analysis parameter view from the perspective of scenarios and capabilities in the pre-set system architecture framework, a risk analysis parameter view is constructed. The risk analysis parameter view is used to trace the risks, threats and hidden dangers brought about by application scenario tasks. Based on the metamodel of the scenario and capability perspective view of the scenario and task development requirements in the pre-defined system architecture framework, a scenario and task development requirements view is constructed. This view is used to obtain the strategic capabilities and strategic capability requirements of the intelligent vehicle cyber-physical system under the application scenario and task. The aforementioned view architecture from the perspective of scenarios and capabilities can include a vision view of the intelligent vehicle cyber-physical system, a stakeholder needs view during the operation phase, an application scenario task analysis view, an application scenario environment analysis view, a standard classification view, a list of intelligent vehicle cyber-physical system capabilities, a capability status and effect analysis view, a measurement index parameter view, a scenario capability constraint view, a risk analysis parameter view, and a scenario and task development requirements view.

[0048] In this embodiment, by refining the view architecture construction process from the perspectives of scenarios and capabilities, the specific construction methods and core functions of 11 specialized views under this perspective are clarified, achieving full-link coverage from the IVCPS system vision and stakeholder needs in the operational phase to application scenarios, capability lists, risks and hidden dangers, and development requirements. It aligns with the characteristics of the IVCPS domain, unifying the design standards, analysis dimensions, and granularity at the scenario and capability levels. It addresses the pain point of inconsistent understandings of top-level requirements, scenario tasks, and system capabilities among multiple stakeholders, avoiding missing elements, logical breaks, or duplication in the design at this level. Simultaneously, it provides accurate and traceable top-level input for the subsequent construction of view architectures from other perspectives, ensuring the hierarchy, completeness, and rationality of the initial architecture model.

[0049] In some embodiments, the multidimensional perspective may further include a running perspective, and S102 may further include: Based on the meta-model of the intelligent vehicle cyber-physical system operation entity classification view from the perspective of the pre-set system architecture framework, an intelligent vehicle cyber-physical system operation entity classification view is constructed. The intelligent vehicle cyber-physical system operation entity classification view is used to sort out the types of operation executors according to the needs of application scenario tasks and strategic capabilities. Based on the metamodel of the runtime strategy view from the perspective of the preset system architecture framework, the runtime strategy view is constructed, and the runtime strategy view obtains the runtime concept of the runtime plan. Based on the meta-model of the operation process view from the perspective of the preset system architecture framework, a first operation process view is constructed. The first operation process view is used to obtain the operation executor and operation activity process in each operation scheme. Based on the meta-model of the runtime port view from the perspective of the preset system architecture framework, the runtime port view is constructed. The runtime port view is used to obtain the connection, interface and information flow of the runtime executor. Based on the meta-model of the runtime process view from the perspective of the preset system architecture framework, a second runtime process view is constructed. The second runtime process view is used to archive the runtime activities of each runtime executor. Based on the meta-model of the measurement indicator parameter view from the perspective of the pre-set system architecture framework, the measurement indicator parameter view is constructed. The measurement indicator parameter view is used to analyze the parameters of the view architecture model and configure them according to the executor type and capability category to obtain the overall indicators. Then, based on the operational activities, quantitative and qualitative indicators are obtained, and the parameter model is constructed. Based on the meta-model of the risk analysis parameter view from the operational perspective in the preset system architecture framework, a risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in each operational scheme. Based on the metamodel of the runtime architecture instance view from the perspective of the preset system architecture framework, the runtime architecture instance view is constructed. The runtime architecture instance view is used to configure parameters for the runtime architecture and simulate it. A suitable parameter scheme is selected and saved as a runtime instance. Based on the meta-model of the operation traceability view from the perspective of the pre-defined system architecture framework, an operation traceability view is constructed. The operation traceability view is used to track the mapping relationship between the capabilities and requirements of operation activities and the capabilities of the intelligent vehicle cyber-physical system. Based on the metamodel of the service development requirements view from the operational perspective within the pre-defined system architecture framework, a service development requirements view is constructed. This view is used to obtain the requirements supporting the implementation of various operational scenarios. The aforementioned operational perspective view architecture may include a classification view of the main operating entities of the intelligent vehicle cyber-physical system, an operational plan strategy view, a first operational process view, an operational port view, a second operational process view, a measurement index parameter view, a risk analysis parameter view, an operational architecture instance view, an operational traceability view, and a service development requirement view.

[0050] In this embodiment, the view architecture construction process from a runtime perspective clarifies the specific construction methods and core functions of 10 specialized views under this perspective, realizing the design transformation from top-level requirements from the perspective of scenarios and capabilities to the actual operation and implementation of the IVCPS system. It unifies the design standards, analysis granularity, and interaction specifications at the runtime level, clearly depicting the collaborative logic, activity processes, interface interactions, and risk control requirements of multiple operating entities within the system. This solves the pain point of traditional designs being unable to accurately depict the complex dynamic interactions of the system and prone to cognitive blind spots. By establishing a mapping relationship between runtime activities and top-level capability requirements through the runtime traceability view, the end-to-end traceability of the architecture design is further strengthened. Simultaneously, it outputs service development requirements, providing precise input for the subsequent construction of the view architecture from a service perspective, ensuring the coherence, feasibility, and logical consistency of the initial architecture model.

[0051] In some embodiments, the multidimensional perspective described above may further include a service perspective, and S102 may further include: Based on the metamodel of the service classification view from the service perspective in the pre-defined system architecture framework, a service classification view is constructed. The service classification view is used to distinguish service types and categories based on the source of input requirements and to formulate a variety of feasible service solutions. Based on the metamodel of the service structure analysis view from the service perspective in the pre-defined system architecture framework, a service structure analysis view is constructed. The service structure analysis view is used to obtain the composition structure of the service and an overview of the service solution. Based on the meta-model of the service process view from the service perspective in the preset system architecture framework, a first service process view is constructed. The first service process view is used to obtain the running execution parties and running activity processes in each solution. Based on the metamodel of the service port view from the service perspective in the preset system architecture framework, the service port view is constructed. The service port view is used to obtain the connection, internal and external interfaces, and information flow of the intelligent vehicle cyber-physical system services. Based on the meta-model of the service flow view from the service perspective in the preset system architecture framework, a second service flow view is constructed. The second service flow view is used to archive the service functions of each intelligent vehicle cyber-physical system service. Based on the meta-model of the measurement indicator parameter view from the service perspective in the preset system architecture framework, the measurement indicator parameter view is constructed. The measurement indicator parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators, and to construct the parameter model. Based on the meta-model of the risk analysis parameter view from the service perspective in the pre-set system architecture framework, a risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in the execution of various intelligent vehicle cyber-physical system services. Based on the metamodel of the service architecture instance view from the service perspective in the preset system architecture framework, a service architecture instance view is constructed. The service architecture instance view is used to configure parameters for the service architecture and simulate it. A suitable parameter scheme is selected and saved as a service architecture instance. Based on the metamodel of the service traceability view from the service perspective in the pre-defined system architecture framework, a service traceability view is constructed. The service traceability view obtains the traceability relationship between the runtime activity requirements and the IVCPS service functions. Based on the metamodel of the resource development requirements view from a service perspective within the pre-defined system architecture framework, a resource development requirements view is constructed. This view supports the requirements for implementing services, i.e., the service capability requirements, and serves as the input for resource development. The service-oriented view architecture described above may include a service classification view, a service structure analysis view, a first service process view, a service port view, a second service process view, a measurement indicator parameter view, a risk analysis parameter view, a service architecture instance view, a service traceability view, and a resource development requirement view.

[0052] In this embodiment, a service-oriented view architecture construction process clarifies the specific construction methods and core functions of 10 specialized views under this perspective, realizing the design transformation from an operational plan to IVCPS system service capabilities. It unifies service-level design standards, analysis granularity, and interface specifications, clearly defining service classifications, structural components, process interactions, and risk control requirements, avoiding functional duplication, logical contradictions, or missing elements in service design. By establishing a mapping relationship between operational activity requirements and service functions through a service traceability view, it further improves the end-to-end traceability of the architecture design. Simultaneously, it outputs resource development requirements, providing precise input for subsequent resource-oriented view architecture construction, ensuring the hierarchical coherence and logical closure of the initial architecture model from operation to service to resource, and improving the feasibility and standardization of the architecture design.

[0053] In some embodiments, the multidimensional perspective may further include a security perspective, and S102 may further include: Based on the meta-model of the risk and control motivation view from a security perspective in the pre-defined system architecture framework, the risk and control motivation view is constructed. The risk and control motivation view is used to capture cyber security risks and conflicts brought about by application scenarios and tasks based on risk analysis, and to design corresponding cyber-side information security protection and control strategies, additions and enhancements to cyber security control strategies, and cyber security control families. Based on the meta-model of the cyber security classification view from a security perspective in the preset system architecture framework, a cyber security classification view is constructed. The cyber security classification view is used to obtain the assets threatened in the current step, the intelligent vehicle cyber-physical system assets that respond to specific risks, and the intelligent vehicle cyber-physical system protection enclave. Based on the meta-model of the cybersecurity constraint view from a security perspective in the pre-defined system architecture framework, a cybersecurity constraint view is constructed. The cybersecurity constraint view is used to capture the constraint items of the cybersecurity control strategy. Based on the metamodel of the cybersecurity traceability view from a security perspective within the pre-defined system architecture framework, a cybersecurity traceability view is constructed. This view is used to capture the traceability relationships between cybersecurity risks, control strategies, capabilities, and assets. The aforementioned security perspective view architecture may include a risk and control motivation view, a cybersecurity classification view, a cybersecurity constraint view, and a cybersecurity traceability view.

[0054] In this embodiment, a security-perspective view architecture construction process is used to clarify the specific construction methods and core functions of four specialized views under this perspective, achieving a deep integration of cybersecurity protection and architecture design within the IVCPS system. This unifies security-level design standards and analysis dimensions, enabling precise capture of cybersecurity risks and conflicts, definition of threatened assets, clarification of security protection constraints, and establishment of a full-link security traceability relationship. It addresses the pain points of traditional designs, such as lagging security design, disconnect from business architecture, and insufficient security risk management. Simultaneously, it improves the security and compliance of the initial architecture model, forms a logical closed loop in collaboration with other perspectives, proactively avoids information security risks, reduces subsequent security remediation costs, and ensures the stable and reliable operation of the IVCPS system.

[0055] In some embodiments, the multidimensional perspective may further include a standard perspective, and S102 may further include: Based on the metamodel of at least one of the standard list view, standard traceability view, and standard requirement view in the pre-defined system architecture framework, construct the standard view architecture. The standard view architecture is used to obtain the standards and regulations involved in this stage and propose the requirements for the standards.

[0056] In this embodiment, a standard-perspective view architecture construction process is used to clarify the construction methods and core functions of relevant views under this perspective, achieving deep integration of IVCPS system architecture design with standards and regulations. It unifies design specifications at the standard level, accurately identifies the standards and regulations involved in each stage of architecture design, and proposes corresponding standard requirements. This solves the pain points of traditional design where compliance requirements are disconnected from architecture design and compliance requirements cannot be accurately implemented. Simultaneously, it improves the compliance and completeness of the initial architecture model, forming a logical closed loop in collaboration with other perspectives. This avoids design rework due to compliance issues from the outset, ensuring that the architecture design complies with industry standards and laws and regulations, and providing strong support for the compliant and large-scale implementation of the IVCPS system.

[0057] In some embodiments, the above-mentioned multidimensional perspective may further include a resource perspective, and S102 may further include: Based on the meta-model of the cyber-physical classification view from the perspective of resources in the pre-defined system architecture framework, a cyber-physical classification view is constructed. The cyber-physical classification view is used to analyze the resource types associated with the implementation of operational activities and service functions in the cyber-physical system of intelligent vehicles. Based on the meta-model of the resource service structure view from the perspective of the pre-set system architecture framework, a resource service structure view is constructed. The resource service structure view is used to analyze the composition structure and functional allocation of the cyber-physical resources required by the intelligent vehicle cyber-physical system in specific operation schemes and services. Based on the meta-model of the resource flow view from the perspective of the pre-set system architecture framework, a first resource flow view is constructed. The first resource flow view is used for the execution parties of each cyber-physical resource and the functional flow of cyber-physical resources in each scheme. Based on the meta-model of the cyber-physical resource port view from the perspective of resources in the pre-defined system architecture framework, the cyber-physical resource port view is constructed. The cyber-physical resource port view is used to obtain the interface, port, and information flow of the cyber-physical resource executor. Based on the meta-model of the measurement indicator parameter view from the resource perspective in the preset system architecture framework, the measurement indicator parameter view is constructed. The measurement indicator parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators, and to construct the parameter model. Based on the meta-model of the cyber-physical resource status view from the perspective of the pre-defined system architecture framework, a cyber-physical resource status view is constructed. The cyber-physical resource status view is used to obtain the relevant status of the execution and implementation of functions of cyber-physical resources at all levels. Based on the meta-model of the resource flow view from the resource perspective in the preset system architecture framework, a second resource flow view is constructed. The second resource flow view is used to archive the cyber-physical resource functions of each cyber-physical resource executor. Based on the meta-model of the risk analysis parameter view from the perspective of resources in the pre-defined system architecture framework, a risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers that exist between system-level resources and between system-level resources and their functions. Based on the meta-model of the cyber-physical resource architecture instance view from the resource perspective in the preset system architecture framework, construct the cyber-physical resource architecture instance view. The cyber-physical resource architecture instance view is used to configure parameters for the resource architecture and simulate it. Select an appropriate parameter scheme and save it as a resource architecture instance. Based on the meta-model of the cyber-physical traceability view from the perspective of resources in the pre-defined system architecture framework, a cyber-physical traceability view is constructed. The cyber-physical traceability view is used to trace the mapping relationship between resources, functions, operational activities and service functions. Based on the metamodel of the cyber-physical resource capability requirement view from the resource perspective in the pre-defined system architecture framework, a cyber-physical resource capability requirement view is constructed. This view is used to propose development requirements for downstream capabilities, structures, and interface ports, serving as input to guide downstream development. The aforementioned resource-centric view architecture may include a cyber-physical classification view, a resource service structure view, a first resource flow view, a cyber-physical resource port view, a measurement index parameter view, a cyber-physical resource status view, a second resource flow view, a risk analysis parameter view, a cyber-physical resource architecture instance view, a cyber-physical traceability view, and a cyber-physical resource capability requirement view. The initial architecture model of the aforementioned intelligent vehicle cyber-physical system can include a view architecture from the perspectives of scenarios and capabilities, operation, services, security, standards, and resources.

[0058] In this embodiment, a view architecture construction process from a resource perspective clarifies the specific construction methods and core functions of 11 specialized views under this perspective, realizing the transformation from service requirements from a service perspective to the design of underlying cyber-physical resources. It unifies the design standards, analysis granularity, and interface specifications at the resource level, resolving the pain points of ambiguous design boundaries and chaotic function allocation in underlying cyber-physical resource design. By establishing a full-link mapping of resources, functions, operational activities, and service functions through a cyber-physical traceability view, it thoroughly connects the core links of architecture design from top to bottom, further improving the full-link traceability of architecture design. Simultaneously, it clarifies the complete composition of the initial architecture model of the intelligent vehicle cyber-physical system, ensuring that the initial architecture model has clear layers, complete elements, and a logical closed loop. The output downstream development requirements provide accurate input for subsequent implementation and development, and in collaboration with other perspectives, it improves the standardization and feasibility of the IVCPS system architecture design, reducing the risks of later integration and development.

[0059] In some embodiments, the multidimensional perspective mentioned above may include a verification perspective, and S103 may specifically include: The initial architecture model is simulated using the preset simulation tools in the verification perspective to obtain the simulation results of the initial architecture model. The simulation results are used to characterize whether the initial architecture model meets the architecture design requirements. If the simulation results indicate that the initial architecture model meets the architecture design requirements, the initial architecture model will be determined as the target architecture model for the intelligent vehicle cyber-physical system. If the simulation results indicate that the initial architecture model does not meet the architecture design requirements, the initial architecture model is optimized until it meets the architecture design requirements, thus obtaining the target architecture model of the intelligent vehicle cyber-physical system.

[0060] The aforementioned simulation tools, for example, can be at least one of architecture modeling software, MATLAB, Modelica, PTV Vissim, SUMO, Prescan, etc.

[0061] The simulation results described above can be used to characterize whether the initial architecture model meets the architecture design requirements.

[0062] In this embodiment, a simulation optimization process from a verification perspective is adopted to clarify the specific methods for simulating, judging results, and iteratively optimizing the initial architecture model based on preset simulation tools, thus forming a closed-loop verification mechanism for architecture design. This mechanism can identify defects, logical contradictions, and performance shortcomings in the initial architecture model in advance during the design phase, solving the pain points of early cognitive blind spots, architecture defects leading to later integration failures, and project rework in traditional design. Through iterative optimization, it ensures that the target architecture model fully meets the architecture design requirements, significantly improving the quality and reliability of the architecture design, reducing later integration and rectification costs, and shortening the development cycle, providing strong support for the efficient implementation of the advanced capabilities of the IVCPS system.

[0063] To facilitate understanding of the architecture design method for the intelligent vehicle cyber-physical system in this application embodiment, the actual application process of this architecture design method for the intelligent vehicle cyber-physical system is described as follows: I. Constructing a domain-specific, multi-layered architectural framework First, such as Figures 2 to 3 As shown, this application, based on concepts and theories from systems engineering and other related disciplines, constructs a dedicated architecture framework for the intelligent vehicle cyber-physical system. In the actual architecture development based on target application scenarios, it clarifies for developers the top-down, abstract-to-concrete configuration architecture design methodology. The IVCPS architecture framework provides specifications and methodologies for architecture design through its perspective, view, and view architecture metamodel, including: Perspective: Corresponding to the basic angles from which architects observe and analyze the system, this approach clarifies the hierarchical structure of the IVCPS system, thereby decoupling the capabilities at each level of the IVCPS system, defining the design scope, and guiding designers at what granularity to work. This method defines seven perspectives: scenario and capability perspective, operational perspective, service perspective, resource perspective, security perspective, standards perspective, and verification perspective.

[0064] Views: Within each given perspective, further focus on specific aspects of concern to the architect (such as classification, structure, connections, processes, etc.). Each view needs to indicate to the designer which specific aspects of the objects of interest should be analyzed and provide corresponding suggestions for the selection of architectural model diagram types.

[0065] View Architecture Metamodel: Based on the definition of each view, its core concepts are abstracted into design elements of the architecture model, and the relationships between these elements are clearly defined and expressed in a model. This metamodel clarifies the element modules that should be included in an architecture model, providing standardized constructs for actual architecture model design, ensuring that elements are complete and relationships are clear during modeling, and avoiding design omissions and logical contradictions.

[0066] II. Provide a standardized architecture design reference process like Figure 4 As shown, the IVCPS architecture design reference process in this application is based on the inherent logical dependencies between the views of the IVCPS architecture framework. It focuses on the transmission of architectural information between the system levels in the development process contained in the IVCPS architecture framework, and pays attention to the trade-offs and decisions in the architecture. When describing them through architectural views, some repetitive descriptions are generated in order to maintain integrity and coherence. The process is a workflow method for architecture design based on the perspectives and views in the IVCPS architecture framework.

[0067] This process clarifies the creation order and iterative relationship of various perspectives and view models, providing architects with a clear modeling starting point and step guidance, effectively solving the problem of "where to start" and "how to proceed" process confusion, and ensuring the systematic nature of the design process and the coherence between models.

[0068] like Figure 5 As shown below, the view architecture design process for each perspective in the above IVCPS architecture will be described in detail.

[0069] (1) View architecture design process from the perspective of scenarios and capabilities This is the first phase of the IVCPS system architecture design. In this phase, when designing the architecture for a specific application scenario of the IVCPS system, the stakeholder analysis (stakeholder list) of the current application scenario serves as the starting point. Based on the stakeholder analysis, the required system capabilities are selected from the IVCPS system capability list, and capability effect models are established. The tasks and environment of the current application scenario are analyzed, and the parameter models of the tasks are defined. Finally, the application scenario instances to be developed based on the IVCPS system are determined, providing top-level definitions, basic support, and design inputs for the next phase of development. The design reference steps for this phase are shown in Table 1.

[0070] Table 1. Stage View Architecture Design Steps from the Perspective of Scenarios and Capabilities Table 2. Security Perspective Stage View Architecture Design Steps (2) View architecture design process from the perspective of operation In this design phase, developers, based on the current IVCPS system operational requirements list, clarify the operational entities involved in each operational plan and establish a classification model, designing an operational concept diagram. Further refinement based on the operational concept involves analyzing the activity flow and parameters of the operational plans. Operational interactions are achieved through activity actions, relying on the interfaces provided by each executor to complete the transmission of information and parameters. The constructed operational activities and operational layer interface / port models can be archived in a library for future development reference and reuse. Simultaneously, developers must comply with relevant laws and standards, comprehensively consider the potential impact, risks, and other constraints of task execution, and ultimately determine the operational instance. The operational activities designed in this phase can be checked for compliance with corresponding requirements by establishing a traceability matrix and conducting simulation verification.

[0071] The runtime architecture design phase aims to clearly describe the task execution process and ultimately identify the requirements for achieving runtime capabilities. This output will serve as a crucial input for service capability design in the logical analysis phase. Meeting these runtime capability requirements is the fundamental goal of service layer capability and some resource layer capability design. The design reference steps for this phase are shown in Table 3.

[0072] Table 3. Steps for Designing the View Architecture in the Operational Perspective Stage (3) Service-oriented view architecture design process The purpose of this phase is to define the required IVCPS services, their included functionalities, and the achievable service levels based on operational capacity needs. These services can be encapsulated and invoked through interfaces; different combinations can enable new capabilities (i.e., emergent capabilities) to address a wider range of needs and scenarios, which is a key characteristic of the IVCPS architecture. The main stakeholders in this phase include system architects, solution providers, operators, system engineers, software engineers, and business architects. They collectively focus on designing services that support operational capabilities and defining their functional specifications and service levels. If designing only a completely new service, this phase is the starting point.

[0073] At this stage, developers focus on designing and implementing corresponding IVCPS services based on input. First, each service has a service interface / port, serving as a type definition for the service role. Service roles connect and interact through the interface / port, and the interaction includes cyber-physical resource executors, operational information, and service signals. By executing service functions and completing interactions, IVCPS services ultimately support the implementation of operational activities. The design process also needs to comprehensively consider relevant risks and standard constraints. Service contracts govern service behavior and effectively constrain operational connections.

[0074] During this process, developers clarified the service categories and multi-level structures of each service and established models by compiling the IVCPS system service requirement list. They further analyzed service function processes, service parameters, and internal and external interfaces / ports. The designed services were then encapsulated and archived into the IVCPS system service function library for future reuse and reference. Simultaneously, developers must adhere to relevant regulations and standards, comprehensively considering the potential impact, risks, and other constraints of the services, ultimately determining the IVCPS system service solution instance for the current application scenario. The service functions designed in this stage can be checked for compliance with the corresponding requirements by establishing a traceability matrix and conducting simulation verification.

[0075] This phase aims to finalize the requirements for implementing service capabilities, serving as input for resource-level analysis and setting the goal for the next phase of resource layer capability design. The design reference steps for this phase are shown in Table 4.

[0076] Table 4 Service Perspective Stage View Architecture Design Steps (4) Resource-based view architecture design process In this phase, the core objective is to construct a solution architecture, namely the CP resource system architecture, based on the needs of operational and service capabilities. This architecture is formed by the integration and interaction of information, physical, and cyber-physical resources (such as software, hardware, network configuration, and intelligent resources) to support the capabilities and requirements defined in the upper-layer operational solutions and services.

[0077] This phase primarily involves analyzing and configuring system-level resources and subsystem-level resources involved in system interactions (white-box analysis of supporting platforms such as the "high-precision map platform" is not required). The goal is to develop an implementable solution architecture and, based on the premise of cross-domain system integration, to propose clear requirements to downstream system-level, subsystem-level, and component-level development, guiding their capability building and resource allocation. Key stakeholders in this phase include system engineers, resource owners, implementers, solution providers, and IT architects. The focus for all parties is on defining a solution architecture that can fulfill upper-level requirements and effectively guide lower-level development.

[0078] During this process, developers, based on service instances and resource lists, clarify the system resource classifications of the IVCPS architecture, the service allocation of each resource, and further establish an IVCPS architecture resource service structure model. They further analyze resource function flows and resource interface / port configurations. They clarify the detailed functions and parameter allocation schemes of each component system resource, and analyze state changes through a state model. Simultaneously, developers must comply with relevant regulations and standards, comprehensively consider the potential impact, risks, and other constraints of actual resource implementation, and ultimately determine the actual resource list and parameters. The designed and configured system functions are then encapsulated and archived into the IVCPS architecture resource system function library for future reuse and reference. The system functions designed in this stage can be checked for compliance with requirements by establishing a traceability matrix and conducting simulation verification.

[0079] This phase aims to finalize the requirements for implementing the resource layer capabilities of the IVCPS system, serving as input for the development of downstream systems, subsystems, and components. The design reference steps for this phase are shown in Table 5.

[0080] Table 5. Resource Perspective Stage View Architecture Design Steps (5) Verification of perspective process The validation and evaluation phase aims to systematically evaluate different solution architectures. Specific tasks include alternative analysis, hypothesis testing, trade-off studies, and testing and validation of actual resource allocation. This phase utilizes various simulation tools (such as architecture modeling software, MATLAB, Modelica, PTV Vissim, SUMO, Prescan, etc.) to simulate, analyze, and optimize the IVCPS architecture model developed in the first four phases. Key stakeholders involved in this phase include system engineers, business architects, requirements engineers, system engineers, solution providers, suppliers, and operators. All parties focus on whether the results of independent and joint system simulations of components, subsystems, and the entire system meet the requirements, and compare, optimize, and ultimately decide on different solutions based on the evaluation results.

[0081] III. Implement it as an operable software tool This application configures and develops the "IVCPS Architecture Model Development and Verification Platform" software tool, which includes the architectural design perspectives, views, architectural model design elements and related definitions and specifications contained in the aforementioned framework, as well as the framework-based architectural design reference process. This software tool incorporates the aforementioned domain-specific IVCPS architecture framework, architecture design-related definitions, specifications, and reference processes, empowering designers in a template-based and wizard-driven manner. Using this tool for architecture design can completely change the extensive approach that relies on natural language documents and general, abstract framework templates, ensuring that the architecture design is based on unified and precise domain semantics and specifications from the outset.

[0082] This application configures the IVCPS architecture framework and architecture design reference process to form a domestically developed IVCPS architecture design modeling software, "IVCPS Architecture Model Development and Verification Platform." This software embeds the IVCPS architecture framework, architecture design reference process, and domain knowledge meta-model, and can be applied to the architecture design of IVCPS systems and vehicle-road-cloud integrated domains. The usage and functions of this software are described below: First, create a new project. Open the "IVCPS Architecture Model Development and Verification Platform" software, click "New Project", create a new project, select "IVCPS Project Template" for the architecture model, and click "Next", as shown in Figure 6(1).

[0083] Name the project “IVCPS_Example” and click the “OK” button to create an IVCPS project, as shown in Figure 6(2).

[0084] In the newly created project, click the "Scenario and Capability Perspective" package next to expand "Scenario and Capability Perspective", right-click "Field Energy-Motivation View", and in the pop-up "New View" dialog box, select "Strategic Motivation Diagram" to expand the IVCPS system architecture model design work, as shown in Figure 6(3).

[0085] From the "Strategic Motivation" column, drag "Opportunities for the Development of the IVCPS System" into the "IVCPS Strategic Motivation Diagram" on the right, and change the element name to: "The Ministry of Transport issued the 'Evaluation Index System for the Construction of a Transportation Powerhouse,' focusing on safety, convenience, efficiency, greenness, and economy to achieve a transportation powerhouse." From the "Strategic Motivation" column, drag "Driving Factors for Building the IVCPS System" into the "IVCPS Strategic Motivation Diagram" on the right, and change the element name to: "The needs of ordinary people for road transportation and their livelihood needs," as shown in Figure 6(4).

[0086] Subsequent modeling work can be carried out by selecting relevant elements according to the perspective and view defined in this report to build an architecture model and run simulation, as shown in Figure 6(5).

[0087] IV. Final Technical Effects This application guides architects to construct system architecture models correctly and systematically, fundamentally solving problems such as chaotic analysis hierarchies, duplicated or missing designs, and broken logical links. Ultimately, it produces a system architecture model that is logically consistent, hierarchically clear, complete in elements, and highly scalable and manageable. This model ensures end-to-end design traceability, from the top-level strategic goals and user requirements of the target application scenario to the functions, logical components, and interaction analysis of each constituent system, as well as the configuration of parameters at each granularity. The architecture model produced by this application lays a solid foundation for early logical verification, impact analysis, and rapid iteration to adapt to technological evolution in IVCPS system development, thereby significantly improving overall design quality and collaborative efficiency, and reducing later integration risks and development costs.

[0088] Based on the architecture design method for intelligent vehicle cyber-physical systems provided in the above embodiments, this application also provides a specific implementation of the architecture design apparatus for intelligent vehicle cyber-physical systems. Please refer to the following embodiments.

[0089] like Figure 7 As shown in the embodiment of this application, the intelligent vehicle cyber-physical system architecture design device 700 may include the following modules: acquisition module 701, construction module 702 and simulation module 703.

[0090] The acquisition module 701 is used to acquire the architectural design requirements of the cyber-physical system of intelligent vehicles; Module 702 is used to respond to architecture design requirements and construct the view architecture of each view from a multi-dimensional perspective in the preset system architecture framework to obtain the initial architecture model of the intelligent vehicle cyber-physical system. Simulation module 703 is used to perform simulation optimization on the initial architecture model to obtain the target architecture model of the intelligent vehicle cyber-physical system.

[0091] The architecture design device for the intelligent vehicle cyber-physical system (IVCPS) of this application embodiment can respond to the architecture design requirements of the IVCPS, construct the view architecture of each view according to the meta-model of each view in the multi-dimensional perspective of the preset system architecture framework, obtain the initial architecture model of the intelligent vehicle IVCPS, and perform simulation optimization on the initial architecture model to obtain the target architecture model of the intelligent vehicle IVCPS. Thus, by standardizing the design path and output standards through a unified architecture framework, this application embodiment can unify the design language and understanding, design boundaries and analysis granularity of multiple stakeholders. This not only enables multiple stakeholders to reach a design consensus, but also results in a clear and logically coherent architecture solution. Furthermore, through standardized architecture modeling and subsequent simulation optimization closed loop, the entire architecture design process is controllable, avoiding problems such as design duplication, contradictions, and omissions in advance, ensuring the traceability of requirements, design, and implementation, and ultimately significantly reducing the risk of project rework and integration failure, compressing development costs and cycles, and supporting the implementation of advanced IVCPS system capabilities.

[0092] As one implementation of this application, in order to provide a unified system architecture framework, the aforementioned device 700 may further include: The first definition module is used to define the architectural framework construction principle based on the intelligent vehicle cyber-physical system, defining multi-dimensional perspectives, with different perspectives corresponding to different levels of concern and angles; The second definition module is used to define at least one view under each perspective based on the concern level and angle corresponding to each perspective. Different views are used to indicate different concerns and suggestions for the selection of architectural model diagrams. The modular expression module is used to model the concerns, design objects, relationships, and textual definitions of each view to obtain the metamodel corresponding to each view; The above-mentioned system architecture framework may include a multi-dimensional perspective, at least one view of each perspective, and a meta-model corresponding to each view.

[0093] In some embodiments, the aforementioned multidimensional perspective may include scene and capability perspectives, and the aforementioned construction module 702 may specifically include: The first building unit is used to respond to the architecture design requirements and construct the vision view of the intelligent vehicle cyber-physical system based on the meta-model of the vision view of the intelligent vehicle cyber-physical system from the perspective of scenarios and capabilities in the preset system architecture framework. The vision view of the intelligent vehicle cyber-physical system is used to obtain the vision for the construction of the intelligent vehicle cyber-physical system from the architecture design requirements. The first building unit mentioned above is also used to construct the stakeholder needs view for the operation phase based on the metamodel and vision of the stakeholder needs view for the operation phase from the perspective of scenarios and capabilities in the preset system architecture framework. The stakeholder needs view for the operation phase is used to obtain the stakeholder needs for the system operation phase. The first building unit mentioned above is also used to construct an application scenario task analysis view based on the metamodel of the application scenario task analysis view from the perspective of scenarios and capabilities in the preset system architecture framework. The application scenario task analysis view is used to obtain the usage conditions and scope of the intelligent vehicle cyber-physical system capabilities of the application scenario, as well as the evaluation aspects and measurement indicators of the ability to realize the application scenario and tasks. The first building unit mentioned above is also used to construct an application scenario environment analysis view based on the metamodel of the application scenario environment analysis view from the perspective of scenarios and capabilities in the preset system architecture framework. The application scenario environment analysis view is used to obtain the scenario environment faced by the intelligent vehicle cyber-physical system. The first building unit mentioned above is also used to construct a standard classification view based on the metamodel of the standard classification view from the perspective of scenarios and capabilities in the preset system architecture framework. The standard classification view is used to obtain the standards and laws and regulations that the application scenario tasks need to follow. The aforementioned first building unit is also used to construct an intelligent vehicle cyber-physical system capability list view based on the meta-model of the intelligent vehicle cyber-physical system capability list view from the perspective of scenarios and capabilities in the preset system architecture framework. The intelligent vehicle cyber-physical system capability list view is used to define the capabilities of the intelligent vehicle cyber-physical system. The first building unit mentioned above is also used to construct a capability status and effect analysis view based on the metamodel of the capability status and effect analysis view from the perspective of scenario and capability in the preset system architecture framework. The capability status and effect analysis view is used to obtain the gap between the capabilities and requirements of the intelligent vehicle cyber-physical system. The first building unit mentioned above is also used to construct a measurement index parameter view based on the meta-model of the measurement index parameter view from the perspective of scenarios and capabilities in the preset system architecture framework. The measurement index parameter view is used for task parameter modeling. The first building unit mentioned above is also used to construct a scene capability constraint view based on the metamodel of the scene capability constraint view from the perspective of the scene and capability in the preset system architecture framework. The scene capability constraint view is used to obtain the constraints and limitations of the current level capability. The aforementioned first building unit is also used to construct a risk analysis parameter view based on the meta-model of the risk analysis parameter view from the perspective of scenarios and capabilities in the preset system architecture framework. The risk analysis parameter view is used to trace the risks, threats and hidden dangers brought about by application scenario tasks. The aforementioned first building unit is also used to construct a scenario and task development requirement view based on the metamodel of the scenario and task development requirement view from the perspective of scenarios and capabilities in the preset system architecture framework. The scenario and task development requirement view is used to obtain the strategic capabilities and strategic capability requirements of the intelligent vehicle cyber-physical system under the application scenario and task. The aforementioned view architecture from the perspective of scenarios and capabilities can include a vision view of the intelligent vehicle cyber-physical system, a stakeholder needs view during the operation phase, an application scenario task analysis view, an application scenario environment analysis view, a standard classification view, a list of intelligent vehicle cyber-physical system capabilities, a capability status and effect analysis view, a measurement index parameter view, a scenario capability constraint view, a risk analysis parameter view, and a scenario and task development requirements view.

[0094] In some embodiments, the multidimensional perspective may further include a runtime perspective, and the construction module 702 may further include: The second building unit is used to construct a classification view of the main operating entities of the intelligent vehicle cyber-physical system based on the meta-model of the classification view of the main operating entities of the intelligent vehicle cyber-physical system from the perspective of the preset system architecture framework. The classification view of the main operating entities of the intelligent vehicle cyber-physical system is used to sort out the types of operating executors according to the needs of application scenario tasks and strategic capabilities. The second building unit mentioned above is also used to construct a running scheme strategy view based on the metamodel of the running scheme strategy view from the running perspective in the preset system architecture framework, and the running scheme strategy view obtains the running concept of the running scheme. Based on the meta-model of the operation process view from the perspective of the preset system architecture framework, a first operation process view is constructed. The first operation process view is used to obtain the operation executor and operation activity process in each operation scheme. The second building unit mentioned above is also used to build a running port view based on the metamodel of the running port view from the running perspective in the preset system architecture framework. The running port view is used to obtain the connection, interface and information flow of the running executor. The aforementioned second building unit is also used to construct a second running process view based on the meta-model of the running process view from the running perspective in the preset system architecture framework. The second running process view is used to archive the running activities of each running executor. The second building unit mentioned above is also used to construct a measurement indicator parameter view based on the meta-model of the measurement indicator parameter view from the perspective of the preset system architecture framework. The measurement indicator parameter view is used to analyze the parameters of the view architecture model and configure them according to the type of executor and the capability category to obtain the overall indicators. Then, based on the running activities, quantitative and qualitative indicators are obtained, and a parameter model is constructed. The second building unit mentioned above is also used to construct a risk analysis parameter view based on the meta-model of the risk analysis parameter view from the perspective of operation in the preset system architecture framework. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in each operation scheme. The second building unit mentioned above is also used to construct a running architecture instance view based on the metamodel of the running architecture instance view from the running perspective in the preset system architecture framework. The running architecture instance view is used to configure parameters for the running architecture and simulate it, select a suitable parameter scheme, and save it as a running instance. The second building unit mentioned above is also used to construct a runtime traceability view based on the meta-model of the runtime traceability view in the preset system architecture framework. The runtime traceability view is used to track the mapping relationship between the capabilities and requirements of runtime activities and the capabilities of the intelligent vehicle cyber-physical system. The second building unit mentioned above is also used to construct a service development requirement view based on the metamodel of the service development requirement view from the runtime perspective in the preset system architecture framework. The service development requirement view is used to obtain the requirements to support the implementation of various runtime schemes. The aforementioned operational perspective view architecture may include a classification view of the main operating entities of the intelligent vehicle cyber-physical system, an operational plan strategy view, a first operational process view, an operational port view, a second operational process view, a measurement index parameter view, a risk analysis parameter view, an operational architecture instance view, an operational traceability view, and a service development requirement view.

[0095] In some embodiments, the multidimensional perspective described above may further include a service perspective, and the construction module 702 may further include: The third building unit is used to construct a service classification view based on the metamodel of the service classification view from the service perspective in the preset system architecture framework. The service classification view is used to distinguish service types and categories based on the source of input requirements and to formulate a variety of feasible service solutions. The aforementioned third building unit is also used to construct a service structure analysis view based on the metamodel of the service structure analysis view from the service perspective in the preset system architecture framework. The service structure analysis view is used to obtain the composition structure of the service and an overview of the service solution. The aforementioned third building unit is also used to construct a first service process view based on the metamodel of the service process view from the service perspective in the preset system architecture framework. The first service process view is used to obtain the running execution parties and running activity processes in each solution. The aforementioned third building unit is also used to construct a service port view based on the metamodel of the service port view from the service perspective in the preset system architecture framework. The service port view is used to obtain the connection, internal and external interfaces, and information flow of the intelligent vehicle cyber-physical system services. The aforementioned third building unit is also used to construct a second service flow view based on the metamodel of the service flow view from the service perspective in the preset system architecture framework. The second service flow view is used to archive the service functions of each intelligent vehicle cyber-physical system service. The third building unit mentioned above is also used to construct a measurement indicator parameter view based on the meta-model of the measurement indicator parameter view from the service perspective in the preset system architecture framework. The measurement indicator parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators to construct a parameter model. The aforementioned third building unit is also used to construct a risk analysis parameter view based on the metamodel of the risk analysis parameter view from the service perspective in the preset system architecture framework. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in the execution of various intelligent vehicle cyber-physical system services. The third building unit mentioned above is also used to build a service architecture instance view based on the metamodel of the service architecture instance view in the service perspective of the preset system architecture framework. The service architecture instance view is used to configure parameters for the service architecture and simulate it, select an appropriate parameter scheme, and save it as a service architecture instance. The aforementioned third building unit is also used to construct a service traceability view based on the metamodel of the service traceability view from the service perspective in the preset system architecture framework. The service traceability view obtains the traceability relationship between the runtime activity requirements and the IVCPS service functions. The third building unit mentioned above is also used to construct a resource development requirement view based on the metamodel of the resource development requirement view from a service perspective in the preset system architecture framework. The resource development requirement view is used to support the requirements for implementing services, that is, the requirements for service capabilities, and is the input for resource development. The service-oriented view architecture described above may include a service classification view, a service structure analysis view, a first service process view, a service port view, a second service process view, a measurement indicator parameter view, a risk analysis parameter view, a service architecture instance view, a service traceability view, and a resource development requirement view.

[0096] In some embodiments, the multidimensional perspective may further include a security perspective, and the construction module 702 may further include: The fourth building unit is used to construct a risk and control motivation view based on the metamodel of the risk and control motivation view from a security perspective in the preset system architecture framework. The risk and control motivation view is used to capture cyber security risks and conflicts brought about by application scenarios and tasks based on risk analysis, and to design corresponding cyber-side information security protection and control strategies, additions and enhancements to cyber security control strategies, and cyber security control families. The aforementioned fourth building unit is also used to construct a cybersecurity classification view based on the meta-model of the cybersecurity classification view from a security perspective in the preset system architecture framework. The cybersecurity classification view is used to obtain the assets threatened in the current step, the intelligent vehicle cyber-physical system assets that respond to specific risks, and the intelligent vehicle cyber-physical system protection enclaves. The aforementioned fourth building unit is also used to construct a cybersecurity constraint view based on the metamodel of the cybersecurity constraint view from a security perspective in the preset system architecture framework. The cybersecurity constraint view is used to capture the constraint items of the cybersecurity control strategy. The fourth building unit mentioned above is also used to construct a cybersecurity traceability view based on the metamodel of the cybersecurity traceability view from a security perspective within the preset system architecture framework. The cybersecurity traceability view is used to capture the traceability relationships between cybersecurity risks, control strategies, capabilities, and assets. The aforementioned security perspective view architecture may include a risk and control motivation view, a cybersecurity classification view, a cybersecurity constraint view, and a cybersecurity traceability view.

[0097] In some embodiments, the multidimensional perspective may further include a standard perspective, and the construction module 702 may further include: The fifth building unit is used to construct a standard-perspective view architecture based on at least one metamodel of the standard list view, standard traceability view, and standard requirement view in the pre-defined system architecture framework. The standard-perspective view architecture is used to obtain the standards and regulations involved in this stage and propose requirements for the standards.

[0098] In some embodiments, the multidimensional perspective may further include a resource perspective, and the construction module 702 may further include: The sixth building unit is used to construct a cyber-physical classification view based on the meta-model of the cyber-physical classification view from the perspective of resources in the preset system architecture framework. The cyber-physical classification view is used to analyze the resource types associated with the implementation of operational activities and service functions in the cyber-physical system of intelligent vehicles. The aforementioned sixth building unit is also used to construct a resource service structure view based on the metamodel of the resource service structure view from the perspective of the preset system architecture framework. The resource service structure view is used to analyze the composition structure and functional allocation of the cyber-physical resources required by the intelligent vehicle cyber-physical system in specific operation schemes and services. The aforementioned sixth building unit is also used to construct a first resource flow view based on the meta-model of the resource flow view from the resource perspective in the preset system architecture framework. The first resource flow view is used for the execution parties of each cyber-physical resource and the functional flow of cyber-physical resources in each scheme. The aforementioned sixth building unit is also used to construct a cyber-physical resource port view based on the meta-model of the cyber-physical resource port view from the perspective of resources in the preset system architecture framework. The cyber-physical resource port view is used to obtain the interface, port, and information flow of the cyber-physical resource executor. The sixth building unit mentioned above is also used to construct a measurement indicator parameter view based on the meta-model of the measurement indicator parameter view from the perspective of the preset system architecture framework. The measurement indicator parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators to construct a parameter model. The aforementioned sixth building unit is also used to construct a cyber-physical resource status view based on the meta-model of the cyber-physical resource status view from the perspective of resources in the preset system architecture framework. The cyber-physical resource status view is used to obtain the relevant status of cyber-physical resources at all levels in executing and implementing functions. The aforementioned sixth building unit is also used to construct a second resource flow view based on the meta-model of the resource flow view from the resource perspective in the preset system architecture framework. The second resource flow view is used to archive the cyber-physical resource functions of each cyber-physical resource executor. The aforementioned sixth building unit is also used to construct a risk analysis parameter view based on the meta-model of the risk analysis parameter view from the perspective of resources in the preset system architecture framework. The risk analysis parameter view is used to obtain the risks and hidden dangers existing between system-level resources and between system-level resources and their functions. The sixth building unit mentioned above is also used to construct a cyber-physical resource architecture instance view based on the meta-model of the cyber-physical resource architecture instance view from the resource perspective in the preset system architecture framework. The cyber-physical resource architecture instance view is used to configure parameters for the resource architecture and simulate it, select a suitable parameter scheme, and save it as a resource architecture instance. The aforementioned sixth building unit is also used to construct an information physical traceability view based on the metamodel of the information physical traceability view from the perspective of resources in the preset system architecture framework. The information physical traceability view is used to trace the mapping relationship between resources, functions, operational activities and service functions. The aforementioned sixth building unit is also used to construct a cyber-physical resource capability requirement view based on the meta-model of the cyber-physical resource capability requirement view from a resource perspective within the preset system architecture framework. This cyber-physical resource capability requirement view is used to propose development requirements for downstream capabilities, structures, and interface ports, serving as input to guide downstream development. The aforementioned resource-centric view architecture may include a cyber-physical classification view, a resource service structure view, a first resource flow view, a cyber-physical resource port view, a measurement index parameter view, a cyber-physical resource status view, a second resource flow view, a risk analysis parameter view, a cyber-physical resource architecture instance view, a cyber-physical traceability view, and a cyber-physical resource capability requirement view. The initial architecture model of the aforementioned intelligent vehicle cyber-physical system can include a view architecture from the perspectives of scenarios and capabilities, operation, services, security, standards, and resources.

[0099] In some embodiments, the aforementioned multidimensional perspective may include a verification perspective, and the aforementioned simulation module 703 may specifically include: The simulation unit is used to simulate the initial architecture model according to the preset simulation tools in the verification perspective, and obtain the simulation results of the initial architecture model. The simulation results are used to characterize whether the initial architecture model meets the architecture design requirements. The determination unit is used to determine the initial architecture model as the target architecture model of the intelligent vehicle cyber-physical system, provided that the simulation results characterize the initial architecture model as meeting the architecture design requirements. The optimization unit is used to optimize the initial architecture model when the simulation results do not meet the architecture design requirements, until the architecture design requirements are met, and thus obtain the target architecture model of the intelligent vehicle cyber-physical system.

[0100] Figure 8 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0101] An electronic device may include a processor 801 and a memory 802 storing computer program instructions.

[0102] Specifically, the processor 801 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0103] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 802 may include removable or non-removable (or fixed) media. Where appropriate, memory 802 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 802 is non-volatile solid-state memory.

[0104] In a particular embodiment, memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0105] The processor 801 reads and executes computer program instructions stored in the memory 802 to implement any of the intelligent vehicle cyber-physical system architecture design methods in the above embodiments.

[0106] In one example, the electronic device may also include a communication interface 803 and a bus 810. For example, Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 810 and complete communication with each other.

[0107] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0108] Bus 810 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 810 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0109] This electronic device can execute the architecture design method of the intelligent vehicle cyber-physical system in the embodiments of this application, thereby achieving the integration Figure 1 and Figure 7 The architecture design method and device for the cyber-physical system of intelligent vehicles are described.

[0110] Furthermore, in conjunction with the architecture design method of the intelligent vehicle cyber-physical system in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the architecture design methods of the intelligent vehicle cyber-physical system in the above embodiments.

[0111] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the intelligent vehicle cyber-physical system architecture design methods described in the above embodiments.

[0112] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0113] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0114] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0115] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0116] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. An architecture design method for an intelligent vehicle cyber-physical system, characterized in that, include: Obtain the architectural design requirements of the intelligent vehicle cyber-physical system; In response to the architecture design requirements, based on the meta-model of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system. The initial architecture model is simulated and optimized to obtain the target architecture model of the intelligent vehicle cyber-physical system.

2. The method according to claim 1, characterized in that, Before constructing the view architecture of each view from a multi-dimensional perspective based on the meta-model of each view in the preset system architecture framework in response to the architecture design requirements, and obtaining the initial architecture model of the intelligent vehicle cyber-physical system, the method further includes: Based on the architectural framework construction principle of the aforementioned intelligent vehicle cyber-physical system, the multi-dimensional perspective is defined, with different perspectives corresponding to different levels and angles of concern; Based on the concern level and angle corresponding to each of the aforementioned perspectives, at least one view is defined under each of the aforementioned perspectives. Different views are used to indicate different concerns and architectural model diagram selection suggestions. The concerns, design objects, relationships, and textual definitions of each view are modeled to obtain the meta-model corresponding to each view; The system architecture framework includes the multi-dimensional perspective, at least one view of each perspective, and a meta-model corresponding to each view.

3. The method according to claim 1, characterized in that, The multi-dimensional perspective includes scenario and capability perspectives. In response to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspectives in the preset system architecture framework, a view architecture for each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system, including: In response to the architecture design requirements, based on the meta-model of the vision view of the intelligent vehicle cyber-physical system from the perspective of scenarios and capabilities in the preset system architecture framework, the vision view of the intelligent vehicle cyber-physical system is constructed. The vision view of the intelligent vehicle cyber-physical system is used to obtain the vision for the construction of the intelligent vehicle cyber-physical system from the architecture design requirements. Based on the metamodel of the stakeholder needs view in the operation phase from the perspective of scenarios and capabilities described in the preset system architecture framework, and the vision, the stakeholder needs view in the operation phase is constructed. The stakeholder needs view in the operation phase is used to obtain the stakeholder needs for the system operation phase. Based on the meta-model of the application scenario task analysis view from the perspective of scenarios and capabilities in the preset system architecture framework, the application scenario task analysis view is constructed. The application scenario task analysis view is used to obtain the usage conditions and scope of the intelligent vehicle cyber-physical system capabilities of the application scenario, the capability evaluation aspects and measurement indicators for realizing the application scenario and tasks. Based on the meta-model of the application scenario environment analysis view from the perspective of scenarios and capabilities in the preset system architecture framework, the application scenario environment analysis view is constructed. The application scenario environment analysis view is used to obtain the scenario environment faced by the intelligent vehicle cyber-physical system. Based on the meta-model of the standard classification view from the perspective of scenarios and capabilities in the preset system architecture framework, the standard classification view is constructed. The standard classification view is used to obtain the standards and laws and regulations that the application scenario tasks need to follow. Based on the meta-model of the intelligent vehicle cyber-physical system capability list view from the perspective of scenarios and capabilities in the preset system architecture framework, the intelligent vehicle cyber-physical system capability list view is constructed. The intelligent vehicle cyber-physical system capability list view is used to define the capabilities of the intelligent vehicle cyber-physical system. Based on the meta-model of the capability status and effect analysis view from the perspective of scenario and capability in the preset system architecture framework, the capability status and effect analysis view is constructed. The capability status and effect analysis view is used to obtain the gap between the capabilities and requirements of the intelligent vehicle cyber-physical system. Based on the meta-model of the measurement index parameter view from the perspective of scenarios and capabilities in the preset system architecture framework, the measurement index parameter view is constructed, and the measurement index parameter view is used for task parameter modeling. Based on the meta-model of the scenario capability constraint view from the perspective of scenario and capability in the preset system architecture framework, the scenario capability constraint view is constructed. The scenario capability constraint view is used to obtain the constraints and limitations of the current level capability. Based on the meta-model of the risk analysis parameter view from the perspective of scenarios and capabilities in the preset system architecture framework, the risk analysis parameter view is constructed. The risk analysis parameter view is used to trace the risks, threats and hidden dangers brought about by application scenario tasks. Based on the metamodel of the scenario and capability perspective view of the scenario and task development requirements view in the preset system architecture framework, the scenario and task development requirements view is constructed. The scenario and task development requirements view is used to obtain the strategic capabilities and strategic capability requirements of the intelligent vehicle cyber-physical system under the application scenario and task. The scenario and capability perspective view architecture includes the vision view of the intelligent vehicle cyber-physical system, the stakeholder needs view of the operation phase, the application scenario task analysis view, the application scenario environment analysis view, the standard classification view, the intelligent vehicle cyber-physical system capability list view, the capability status and effect analysis view, the measurement index parameter view, the scenario capability constraint view, the risk analysis parameter view, and the scenario and task development requirements view.

4. The method according to claim 3, characterized in that, The multi-dimensional perspective also includes an operational perspective. Responding to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system, further including: Based on the meta-model of the intelligent vehicle cyber-physical system operation entity classification view from the perspective of operation in the preset system architecture framework, the intelligent vehicle cyber-physical system operation entity classification view is constructed. The intelligent vehicle cyber-physical system operation entity classification view is used to sort out the types of operation executors according to the needs of application scenario tasks and strategic capabilities. Based on the metamodel of the operation plan strategy view from the operation perspective in the preset system architecture framework, the operation plan strategy view is constructed, and the operation plan strategy view obtains the operation concept of the operation plan; Based on the meta-model of the operation process view from the operation perspective in the preset system architecture framework, a first operation process view is constructed. The first operation process view is used to obtain each operation executor and operation activity process in each operation scheme. Based on the meta-model of the runtime port view from the runtime perspective in the preset system architecture framework, the runtime port view is constructed. The runtime port view is used to obtain the connection, interface, and information flow of the runtime executor. Based on the meta-model of the operation process view from the operation perspective in the preset system architecture framework, a second operation process view is constructed. The second operation process view is used to archive the operation activities of each of the operation executors. Based on the meta-model of the measurement indicator parameter view under the operation perspective in the preset system architecture framework, the measurement indicator parameter view is constructed. The measurement indicator parameter view is used to analyze the parameters of the view architecture model and configure them according to the executor type and capability category to obtain the overall indicators. Then, based on the operation activities, quantitative and qualitative indicators are obtained, and the parameter model is constructed. Based on the meta-model of the risk analysis parameter view from the operational perspective in the preset system architecture framework, the risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in each of the operational schemes. Based on the meta-model of the runtime architecture instance view from the runtime perspective in the preset system architecture framework, the runtime architecture instance view is constructed. The runtime architecture instance view is used to configure parameters for the runtime architecture and simulate it, select an appropriate parameter scheme, and save it as a runtime instance. Based on the meta-model of the operation traceability view from the operation perspective described in the preset system architecture framework, the operation traceability view is constructed. The operation traceability view is used to track the mapping relationship between the capabilities and requirements of operation activities and the capabilities of the intelligent vehicle cyber-physical system. Based on the metamodel of the service development requirements view from the operational perspective described in the preset system architecture framework, the service development requirements view is constructed. The service development requirements view is used to obtain the requirements supporting the implementation of each of the operational schemes. The operational perspective view architecture includes the following: the operational entity classification view of the intelligent vehicle cyber-physical system, the operational scheme strategy view, the first operational process view, the operational port view, the second operational process view, the measurement index parameter view, the risk analysis parameter view, the operational architecture instance view, the operational traceability view, and the service development requirement view.

5. The method according to claim 4, characterized in that, The multi-dimensional perspective also includes a service perspective. In response to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system. This also includes: Based on the metamodel of the service classification view from the service perspective in the preset system architecture framework, the service classification view is constructed. The service classification view is used to distinguish service types and categories based on the source of input requirements and to formulate a variety of feasible service solutions. Based on the metamodel of the service structure analysis view from the service perspective in the preset system architecture framework, the service structure analysis view is constructed. The service structure analysis view is used to obtain the composition structure of the service and an overview of the service solution. Based on the meta-model of the service process view from the service perspective described in the preset system architecture framework, a first service process view is constructed. The first service process view is used to obtain the running execution parties and running activity processes in each solution. Based on the meta-model of the service port view from the service perspective in the preset system architecture framework, the service port view is constructed. The service port view is used to obtain the connection, internal and external interfaces, and information flow of intelligent vehicle cyber-physical system services. Based on the meta-model of the service flow view from the service perspective in the preset system architecture framework, a second service flow view is constructed. The second service flow view is used to archive the service functions of each intelligent vehicle cyber-physical system service. Based on the meta-model of the service perspective measurement indicator parameter view in the preset system architecture framework, the measurement indicator parameter view is constructed. The measurement indicator parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators, and construct the parameter model. Based on the meta-model of the risk analysis parameter view from the service perspective in the preset system architecture framework, the risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers existing in the execution of various intelligent vehicle cyber-physical system services. Based on the metamodel of the service architecture instance view from the service perspective in the preset system architecture framework, the service architecture instance view is constructed. The service architecture instance view is used to configure parameters for the service architecture and simulate it, select an appropriate parameter scheme, and save it as a service architecture instance. Based on the metamodel of the service traceability view from the service perspective in the preset system architecture framework, the service traceability view is constructed, and the service traceability view obtains the traceability relationship between the operational activity requirements and the IVCPS service functions. Based on the metamodel of the resource development requirements view from a service perspective described in the pre-defined system architecture framework, the resource development requirements view is constructed. This resource development requirements view is used to support the requirements for implementing services, i.e., the requirements for service capabilities, and serves as the input for resource development. The service-oriented view architecture includes the service classification view, the service structure analysis view, the first service process view, the service port view, the second service process view, the measurement index parameter view, the risk analysis parameter view, the service architecture instance view, the service traceability view, and the resource development requirements view.

6. The method according to claim 5, characterized in that, The multi-dimensional perspective also includes a security perspective. In response to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system, which further includes: Based on the meta-model of the risk and control motivation view from a security perspective in the preset system architecture framework, the risk and control motivation view is constructed. The risk and control motivation view is used to capture cyber security risks and conflicts brought about by application scenarios and tasks based on risk analysis, and to design corresponding cyber-side information security protection and control strategies, additions and enhancements to cyber security control strategies, and cyber security control families. Based on the meta-model of the cyber security classification view from the security perspective described in the preset system architecture framework, the cyber security classification view is constructed. The cyber security classification view is used to obtain the assets threatened in the current step, the intelligent vehicle cyber-physical system assets that respond to specific risks, and the intelligent vehicle cyber-physical system protection enclave. Based on the meta-model of the cyber security constraint view from the security perspective in the preset system architecture framework, the cyber security constraint view is constructed, and the cyber security constraint view is used to capture the constraint items of the cyber security control strategy. Based on the meta-model of the cybersecurity traceability view from a security perspective described in the pre-defined system architecture framework, the cybersecurity traceability view is constructed. This cybersecurity traceability view is used to capture the traceability relationships between cybersecurity risks, control strategies, capabilities, and assets. The security perspective view architecture includes the risk and control motivation view, the cybersecurity classification view, the cybersecurity constraint view, and the cybersecurity traceability view.

7. The method according to claim 6, characterized in that, The multi-dimensional perspective also includes a standard perspective. In response to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system. This also includes: Based on the metamodel of at least one of the standard list view, standard traceability view, and standard requirement view under the standard perspective in the preset system architecture framework, the view architecture of the standard perspective is constructed. The view architecture of the standard perspective is used to obtain the standards and regulations involved in this stage and propose the requirements for the standards.

8. The method according to claim 7, characterized in that, The multi-dimensional perspective also includes a resource perspective. In response to the architecture design requirements, based on the meta-models of each view under the multi-dimensional perspective in the preset system architecture framework, the view architecture of each perspective is constructed to obtain the initial architecture model of the intelligent vehicle cyber-physical system, which further includes: Based on the meta-model of the cyber-physical classification view from the resource perspective in the preset system architecture framework, the cyber-physical classification view is constructed. The cyber-physical classification view is used to analyze the resource types associated with the implementation of operational activities and service functions in the cyber-physical system of intelligent vehicles. Based on the meta-model of the resource service structure view from the resource perspective in the preset system architecture framework, the resource service structure view is constructed. The resource service structure view is used to analyze the composition structure and functional allocation of the cyber-physical resources required by the intelligent vehicle cyber-physical system in specific operation schemes and services. Based on the meta-model of the resource flow view from the resource perspective described in the preset system architecture framework, a first resource flow view is constructed. The first resource flow view is used for the execution parties of each cyber-physical resource and the functional flow of cyber-physical resources in each scheme. Based on the meta-model of the cyber-physical resource port view from the resource perspective in the preset system architecture framework, the cyber-physical resource port view is constructed. The cyber-physical resource port view is used to obtain the interface, port, and information flow of the cyber-physical resource executor. Based on the meta-model of the measurement index parameter view from the resource perspective in the preset system architecture framework, the measurement index parameter view is constructed. The measurement index parameter view is used to analyze and configure the parameters of the above view architecture model based on quantitative and qualitative indicators, and to construct a parameter model. Based on the meta-model of the cyber-physical resource status view from the resource perspective in the preset system architecture framework, the cyber-physical resource status view is constructed. The cyber-physical resource status view is used to obtain the relevant status of cyber-physical resources at all levels in executing and implementing functions. Based on the meta-model of the resource flow view from the resource perspective in the preset system architecture framework, a second resource flow view is constructed. The second resource flow view is used to archive the cyber-physical resource functions of each cyber-physical resource executor. Based on the meta-model of the risk analysis parameter view from the resource perspective in the preset system architecture framework, the risk analysis parameter view is constructed. The risk analysis parameter view is used to obtain the risks and hidden dangers existing between system-level resources and between system-level resources and their functions. Based on the meta-model of the cyber-physical resource architecture instance view from the resource perspective in the preset system architecture framework, the cyber-physical resource architecture instance view is constructed. The cyber-physical resource architecture instance view is used to configure parameters for the resource architecture and simulate it, select a suitable parameter scheme, and save it as a resource architecture instance. Based on the meta-model of the information physical traceability view from the resource perspective in the preset system architecture framework, the information physical traceability view is constructed. The information physical traceability view is used to trace the mapping relationship between resources, functions, operational activities and service functions. Based on the metamodel of the cyber-physical resource capability requirement view from the resource perspective described in the preset system architecture framework, the cyber-physical resource capability requirement view is constructed. This view is used to propose development requirements for downstream capabilities, structures, and interface ports, serving as input to guide downstream development. The resource-centric view architecture includes the cyber-physical classification view, the resource service structure view, the first resource process view, the cyber-physical resource port view, the measurement index parameter view, the cyber-physical resource status view, the second resource process view, the risk analysis parameter view, the cyber-physical resource architecture instance view, the cyber-physical traceability view, and the cyber-physical resource capability requirement view. The initial architecture model of the intelligent vehicle cyber-physical system includes the view architecture from the perspectives of scenarios and capabilities, operation, services, security, standards, and resources.

9. The method according to claim 1, characterized in that, The multi-dimensional perspective includes a verification perspective. The simulation optimization of the initial architecture model to obtain the target architecture model of the intelligent vehicle cyber-physical system includes: The initial architecture model is simulated using a preset simulation tool in the verification perspective to obtain the simulation results of the initial architecture model. The simulation results are used to characterize whether the initial architecture model meets the architecture design requirements. If the simulation results indicate that the initial architecture model meets the architecture design requirements, the initial architecture model is determined as the target architecture model of the intelligent vehicle cyber-physical system. If the simulation results indicate that the initial architecture model does not meet the architecture design requirements, the initial architecture model is optimized until the architecture design requirements are met, thereby obtaining the target architecture model of the intelligent vehicle cyber-physical system.

10. An architecture design device for an intelligent vehicle cyber-physical system, characterized in that, The device includes: The acquisition module is used to acquire the architectural design requirements of the intelligent vehicle cyber-physical system; The construction module is used to respond to the architecture design requirements and construct the view architecture of each view from a multi-dimensional perspective in the preset system architecture framework, so as to obtain the initial architecture model of the intelligent vehicle cyber-physical system. The simulation module is used to perform simulation optimization on the initial architecture model to obtain the target architecture model of the intelligent vehicle cyber-physical system.

11. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the architecture design method of the intelligent vehicle cyber-physical system as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the architecture design method of the intelligent vehicle cyber-physical system as described in any one of claims 1-9.

13. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device causes the electronic device to perform the architecture design method of the intelligent vehicle cyber-physical system as described in any one of claims 1-9.

Images