An MBSE-based automobile safety sandbox supervision method, device and equipment

Abstract

The application provides an MBSE-based automobile safety sandbox supervision method, device and equipment, and relates to the technical field of automobile safety supervision. It aims to solve the problems of ambiguity in document description of traditional architecture design, lag in design defect discovery and high repair cost. The method comprises the following steps: analyzing the demand of automobile safety sandbox supervision business scenario through SysML language, constructing demand model and use case model; based on the demand and use case model, decomposing the functions of automobile safety sandbox supervision cloud platform and distributing them to subsystems, and constructing function architecture model by using activity diagram and sequence diagram; constructing logical architecture model and physical architecture model through function architecture model; integrating the above models to form system model, identifying and correcting design defects through simulation test. The application realizes digital modeling and early simulation verification of supervision process, improves the rationality and accuracy of architecture, and reduces the repair cost.

Description

Technical Field

[0001] This application relates to the field of automotive safety sandbox regulatory technology, and more specifically, to an automotive safety sandbox regulatory method, apparatus, and equipment based on MBSE. Background Technology

[0002] With the rapid development of intelligent and connected vehicle technologies, automotive safety sandbox supervision, as a key means to ensure vehicle safety and regulate industry development, faces increasing demands for regulatory efficiency, data management capabilities, and structural rationality. Currently, my country's automotive safety sandbox supervision still mainly relies on offline processes. Material submissions are mostly done by mail or email, technical assessments depend on on-site verification or email feedback, and test data is mostly stored and managed by the companies themselves, lacking a unified storage, sharing, and analysis platform.

[0003] In terms of architecture design, traditional monitoring systems often adopt document-based systems engineering methods. Design descriptions rely on natural language, which can easily lead to ambiguity. Furthermore, the deliverables of each design phase are fragmented, resulting in high communication costs and making it difficult to reuse and collaborate on design models. At the same time, traditional evaluation methods are mainly based on static review and rely excessively on expert experience. Potential system defects are often only discovered in the later stages of design or actual operation, leading to high repair costs and long cycles.

[0004] Furthermore, existing business processes lack standardized process control and task allocation mechanisms, and information is not readily available between departments, making it difficult to form a closed-loop regulatory system and resulting in delayed evaluation and feedback. Against this backdrop, Model-Based Systems Engineering (MBSE) has gradually become the preferred solution for complex system architecture design due to its advantages such as early modeling, unified model management, and dynamic simulation verification. Therefore, there is an urgent need to build an MBSE-based automotive safety sandbox regulatory cloud platform to address many challenges in existing regulatory models and architecture design. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method, device and equipment for supervising automotive safety sandboxes based on MBSE, so as to solve the problems of cumbersome business processes, scattered data, ambiguous architecture design and difficulty in simulation verification in the prior art.

[0006] In a first aspect, embodiments of this application provide a vehicle safety sandbox regulatory method based on MBSE, the method comprising: Based on the business scenario of automotive safety sandbox supervision, system requirements analysis is conducted, and a requirement model reflecting the hierarchical relationship of requirements and a use case model reflecting the interaction relationship between the automotive safety sandbox supervision cloud platform and external roles are constructed using the SysML language. Based on the aforementioned requirement model and use case model, the functions used in the automotive safety sandbox regulatory cloud platform are decomposed and allocated to different subsystems. Using SysML activity diagrams and sequence diagrams, a functional architecture model is constructed, which includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocols between the subsystems. Based on the aforementioned functional architecture model, a logical architecture model is designed using module definition diagrams and internal module diagrams for the logical and physical architectures of the automotive safety sandbox regulatory cloud platform, and a physical architecture model is designed using parameter diagrams and deployment diagrams. Based on the system model of the automotive safety sandbox regulatory cloud platform, which integrates the aforementioned requirement model, functional architecture model, logical architecture model, and physical architecture model, executable code is generated and simulation tests are performed to identify design defects and conduct iterative optimization.

[0007] In conjunction with the first aspect, this application provides a first possible implementation of the first aspect, wherein a logical architecture model is designed using a module definition diagram and an internal module diagram, and a physical architecture model is designed using a parameter diagram and a deployment diagram, including: configuring corresponding model construction methods based on the SysML language for the characteristics of the logical architecture and the physical architecture respectively; and executing the model construction methods to construct the logical architecture model and the physical architecture model of the automotive safety sandbox regulatory cloud platform respectively.

[0008] In conjunction with the first aspect, this application provides a second possible implementation of the first aspect, wherein the model construction method is executed to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform, respectively, including: abstracting the behavior carrier into logical components with static responsibilities according to the behavioral logic described by the activity model; defining the collaboration interface between the logical components according to the interaction protocol described by the sequence model; and formally describing the logical components and collaboration interfaces through a module definition diagram to construct the logical architecture model. In conjunction with the first aspect, this application provides a third possible implementation of the first aspect, wherein, after defining the collaboration interface between the logical components and formally describing the logical components and collaboration interface through a module definition diagram to construct a logical architecture model, the implementation includes: defining physical instantiation of the logical components in the logical architecture model corresponding to the automotive safety risk identification scenario through a deployment diagram; establishing parameter constraint relationships of the logical components through a parameter diagram, which, together with the physical instantiation definition, constitutes the physical architecture model of the automotive safety sandbox regulatory cloud platform.

[0009] In conjunction with the first aspect, this application provides a fourth possible implementation of the first aspect, wherein a functional architecture model is constructed including an activity model describing the behavior of subsystems and a sequence model describing the interaction relationships between subsystems, comprising: for each subsystem and its corresponding key business process, constructing a SysML activity diagram describing its internal behavioral logic and a SysML sequence diagram describing the interaction protocol between them; and fusing the activity model and the sequence model to construct the functional architecture model of the automotive safety sandbox regulatory cloud platform.

[0010] In conjunction with the first aspect, this application provides a fifth possible implementation of the first aspect, wherein, based on the requirement model and the use case model, the functions of the automotive safety sandbox supervision cloud platform for automotive safety sandbox supervision are decomposed, including: mapping high-level functional objectives from the requirement model and identifying key interactive behaviors from the use case model; cross-analyzing and merging the high-level functional objectives and the key interactive behaviors to form a list of functional characteristics, so as to obtain the functional decomposition result.

[0011] In conjunction with the first aspect, this application provides a sixth possible implementation of the first aspect, wherein a requirement model reflecting the hierarchical relationship of requirements and a use case model reflecting the interaction relationship between the automotive safety sandbox regulatory cloud platform for automotive safety sandbox supervision and external roles are constructed using the SysML language. This includes: obtaining multi-dimensional original requirements in the field of automotive safety sandbox supervision, and structurally analyzing and classifying the multi-dimensional original requirements, expressing them in a hierarchical graphical model to obtain the requirement model; based on the requirement model and stakeholder analysis, identifying all external participant roles that need to interact and defining corresponding use cases to construct a use case model.

[0012] Secondly, embodiments of this application provide an MBSE-based automotive safety sandbox monitoring device, the device comprising: The analysis module is used to perform system requirements analysis based on the business scenarios of automotive safety sandbox supervision. It uses SysML language to construct a requirement model that reflects the hierarchical relationship of requirements and a use case model that reflects the interaction relationship between the automotive safety sandbox supervision cloud platform and external roles. The decomposition module is used to decompose the functions of the automotive safety sandbox regulatory cloud platform based on the requirement model and the use case model and allocate them to different subsystems. It constructs a functional architecture model that includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocol between the subsystems through SysML activity diagrams and sequence diagrams. The design module is used to design the logical architecture model of the automotive safety sandbox regulatory cloud platform using module definition diagrams and internal module diagrams, and to design the physical architecture model using parameter diagrams and deployment diagrams, based on the functional architecture model. An integration module is used to generate executable code and perform simulation tests on the system model of the automotive safety sandbox regulatory cloud platform, which is integrated based on the aforementioned requirement model, functional architecture model, logical architecture model, and physical architecture model, in order to identify design defects and perform iterative optimization.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of any of the MBSE-based automotive safety sandbox monitoring methods described in the present application.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the MBSE-based automotive safety sandbox monitoring methods described in the present application.

[0015] This application provides a vehicle safety sandbox regulatory method based on MBSE. By introducing the SysML modeling language, it transforms traditional document-driven design into model-driven design, eliminating ambiguity in design descriptions. By constructing multi-dimensional models encompassing requirements, functions, logic, and physical aspects, and ultimately integrating them into an executable system model for simulation testing, it enables the early detection and correction of defects, significantly reducing remediation costs. Furthermore, this method achieves unified modeling of regulatory data and standardized description of processes, providing technical support for cross-departmental collaborative supervision and the reuse and expansion of platform architecture, effectively improving regulatory efficiency and system reliability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating an MBSE-based automotive safety sandbox regulatory method provided in an embodiment of this application is shown. Figure 2 This application provides a schematic diagram of the design phases according to an embodiment. Figure 3 This illustration shows a schematic diagram of system requirements analysis provided in an embodiment of this application; Figure 4 A schematic diagram of a system use case provided in an embodiment of this application is shown; Figure 5 A schematic diagram of system activities provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the system sequence provided in an embodiment of this application is shown; Figure 7 This illustration shows a schematic diagram of the module definition provided in an embodiment of this application; Figure 8 A schematic diagram of the internal modules provided in an embodiment of this application is shown; Figure 9 This paper illustrates a schematic diagram of the system model simulation verification process provided in an embodiment of this application. Figure 10 This paper shows a structural block diagram of an MBSE-based automotive safety sandbox monitoring device provided in an embodiment of this application; Figure 11 A structural block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of this application, and not all embodiments.

[0019] Example 1 like Figure 1 As shown, this application provides a vehicle safety sandbox regulatory method based on MBSE, the method comprising: S101. Based on the business scenario of automotive safety sandbox supervision, conduct system requirements analysis, and construct a requirement model reflecting the hierarchical relationship of requirements and a use case model reflecting the interaction relationship between the automotive safety sandbox supervision cloud platform and external roles using SysML language. S102. Based on the requirement model and the use case model, decompose the functions used for the automotive safety sandbox regulatory cloud platform and allocate them to different subsystems. Using SysML activity diagrams and sequence diagrams, construct a functional architecture model that includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocols between the subsystems. S103. Using the aforementioned functional architecture model, a logical architecture model is designed for the logical and physical architectures of the automotive safety sandbox regulatory cloud platform using module definition diagrams and internal module diagrams, and a physical architecture model is designed using parameter diagrams and deployment diagrams. S104. Based on the system model of the automotive safety sandbox regulatory cloud platform integrated by the aforementioned requirement model, functional architecture model, logical architecture model, and physical architecture model, generate executable code and conduct simulation tests to identify design defects and perform iterative optimization.

[0020] In this application, the automotive safety sandbox supervision cloud platform includes the following stages: requirement model design stage, functional architecture design stage, logical architecture design stage, physical architecture design stage, and simulation verification and optimization stage, such as... Figure 2 As shown, the above stages are described in steps S101-S04.

[0021] In step S101, the requirements model design phase is executed. In this phase, based on the users and pain points in the business scenario of automotive safety sandbox supervision, the system requirements are comprehensively broken down from multiple dimensions, including strategy, system, stakeholders, security, and services. The strategic layer focuses on improving regulatory efficiency; the system layer clarifies the operational requirements of the automotive safety sandbox supervision platform; the stakeholder layer covers the operational requirements of market regulatory departments, automotive companies, testing institutions, and other roles; the security layer clarifies data encryption and access control; and the service layer focuses on process simplification and data sharing. Through multi-dimensional requirements analysis, a complete requirements list is formed, and further broken down into three top-level capability sets: improving work efficiency, standardizing sandbox supervision workflows, and strengthening data management service capabilities. Each top-level capability set is further decomposed into several sub-capability sets. Based on this, a requirements model reflecting the hierarchical relationship of requirements is constructed using SysML language (which can be implemented using modeling tools such as MagicDraw and Papyrus), such as... Figure 3 As shown, and the use case model reflecting the interaction between the automotive safety sandbox regulatory cloud platform and external roles for automotive safety sandbox regulation, such as... Figure 4 As shown. Figure 3 The subset of top-level capabilities for improving work efficiency includes enterprise information management, automatic task allocation, real-time notifications, and enterprise personnel management; the subset of top-level capabilities for standardizing sandbox workflows includes process management, management analysis and evaluation, risk warning, and technology assessment; and the subset of top-level capabilities for strengthening data management services includes data management, data retrieval, data application, and data sharing. In this step, the core operational processes between the system and external roles identified from the use case model are called key interaction behaviors and will be used in subsequent function decomposition.

[0022] In the specific implementation of step S101, one embodiment is as follows: A requirement model reflecting the hierarchical relationship of requirements and a use case model reflecting the interaction relationship between the automotive safety sandbox regulatory cloud platform and external roles are constructed using the SysML language, including: S1011. Obtain the multi-dimensional original requirements in the field of automotive safety sandbox supervision, and analyze and classify the multi-dimensional original requirements in a structured manner, and express them in a hierarchical graphical model to obtain the requirement model. S1012. Based on the aforementioned requirement model and stakeholder analysis, identify all external participant roles that need to interact and define corresponding use cases to construct a use case model.

[0023] In steps S1011-S1012, multi-dimensional original requirements in the automotive safety sandbox regulatory field are obtained, including multiple dimensions such as strategy, system, stakeholders, safety, and services. These requirements are then structured, analyzed, and categorized. The derivation, dependency, and conflict relationships between requirements are identified, and expressed using a hierarchical graphical model. The top-level capability set, its corresponding sub-capability sets, and specific requirements are presented hierarchically, clearly depicting the attribution, logical connections, and constraints of each requirement. This forms a requirement model reflecting the hierarchy and relationships of requirements, thereby achieving visualized and structured management of requirements. This avoids the ambiguity and vagueness of traditional document-based requirement descriptions, allowing all stakeholders to accurately understand the meaning of the requirements and reducing communication bias. Based on the requirement model and stakeholder analysis, all external participant roles requiring interaction are identified, and corresponding use cases are defined to construct a use case model. Based on this model, the external interaction subjects of the automotive safety sandbox regulatory cloud platform are clarified, including various roles such as regulatory department staff, automotive company applicants, and testing agency operators. The interaction scenarios, operation processes, and input / output information between each role and the automotive safety sandbox regulatory cloud platform are analyzed, such as... Figure 4 As shown, the use case diagram clearly presents the interaction logic and permission boundaries between the automotive safety sandbox regulatory cloud platform and various external roles, clarifies the triggering conditions and execution results of each interaction link, and ensures that the design of the automotive safety sandbox regulatory cloud platform fits the actual business operation scenario and meets the interaction needs of various roles, providing a clear basis for subsequent functional architecture design and interface design.

[0024] In step S102, the process switches from the requirements model design phase to the functional architecture design phase. In the functional architecture design phase, this application decomposes the functions of the automotive safety sandbox regulatory cloud platform based on the requirements model and use case model. Specifically, high-level functional objectives are mapped from the requirements model, key interactive behaviors are identified from the use case model, and a list of functional characteristics is formed after cross-analysis. The decomposed functions are then allocated to nine sub-functional systems: regulatory service management, sandbox testing, data collection, data quality management, data analysis and mining, data services, data display, risk warning, and data storage. This ensures that each decomposed function corresponds to a specific requirement point in the requirements model and can support the interaction scenarios and operation processes of the corresponding roles in the use case model, avoiding functional omissions or redundancy. The functional allocation of each subsystem is interconnected and collaboratively supportive, forming a complete platform functional system. Based on the key functions of each subsystem, a functional architecture model is constructed in strict accordance with the MBSE modeling specifications, including activity models describing the behavior of subsystems and sequence models describing the interaction relationships between subsystems. For each subsystem and its key business processes, an activity model describing its internal behavioral logic (e.g., SysML activity diagrams) is constructed. Figure 5 As shown), a sequence model describing the interaction protocol between subsystems is constructed using SysML sequence diagrams (e.g., Figure 6 (As shown). By integrating the activity model and the sequence model, a complete functional architecture model is constructed.

[0025] The data acquisition subsystem and data quality management subsystem provide the foundation for subsequent data processing and analysis. The analysis results of the data analysis and mining subsystem and the data statistical analysis subsystem are presented to various roles through the data display subsystem and provide data support for the risk warning subsystem. The regulatory service management subsystem coordinates the operation of various subsystems. The testing process of the sandbox testing subsystem is deeply linked with various data-related subsystems. The data service subsystem realizes the sharing and interaction of data among various subsystems. Ultimately, all requirements in the requirement model are fully implemented, and all interaction requirements between the system and external roles in the use case model are met. This ensures that the automotive safety sandbox regulatory cloud platform can operate efficiently, in a standardized and reliable manner, giving full play to the modeling advantages of the MBSE method and improving regulatory effectiveness and platform usability.

[0026] In the specific implementation of step S102, one embodiment is as follows: based on the demand model and the use case model, the functions of the automotive safety sandbox supervision cloud platform for automotive safety sandbox supervision are decomposed, including: S10211. Obtain high-level functional objectives from the requirements model and identify key interactive behaviors from the use case model, respectively. S10212. Cross-analyze and merge the high-level functional objectives and the key interactive behaviors to form a functional characteristic list, so as to obtain the functional decomposition results.

[0027] In steps S10211-S10212, the requirement model of this application presents three top-level capability sets and their subordinate sub-capability sets in a graphical and hierarchical form: "improving work efficiency, standardizing sandbox supervision workflow, and strengthening data management service capabilities." This ensures that each high-level functional objective accurately carries the core requirements of the corresponding need. For example, from the top-level capability set of "standardizing sandbox supervision workflow," four high-level functional objectives are mapped: "full-process control of sandbox testing, standardized application review, traceable testing process, and result review and archiving." These correspond to the full-process sub-requirements in the requirement model regarding sandbox testing application, implementation, feedback, and archiving. Key interactive behaviors are identified from the use case model. Taking the interaction scenario of each external role as the starting point, the use case process is broken down one by one to extract core operations. Each external role has its corresponding key interactive behaviors, and all key interactive behaviors are specific and executable operations. For example, for market supervision work... The system identifies seven key interactive behaviors—"permission allocation, task assignment, review and approval, data query, risk monitoring, statistical analysis, and process supervision"—to focus on the actual interaction scenarios between the automotive safety sandbox regulatory cloud platform and external roles. Cross-analysis examines the correspondence between each high-level functional objective and the key interactive behaviors, and also analyzes whether there is overlap or intersection between key interactive behaviors corresponding to different high-level functional objectives. Based on this cross-analysis, the high-level functional objectives and key interactive behaviors are merged and optimized, eliminating duplicate and redundant content, supplementing missing functional points, and classifying and integrating similar functions. This ultimately forms a functional characteristic list covering nine major categories and their corresponding specific functions: "platform overall control, role and permission management, sandbox testing control, data collection management, data quality control, data analysis and mining, data sharing services, risk warning control, and statistical analysis services."

[0028] It should be noted that the "key interactive behaviors" mentioned in this application refer to the core operational processes or interaction scenarios between the system and external participants (such as regulatory authorities, automobile companies, testing institutions, etc.) identified from the use case model, which are used to guide subsequent functional decomposition and architecture design.

[0029] In the specific implementation of step S102, another embodiment is as follows: a functional architecture model is constructed, including an activity model describing the behavior of subsystems and a sequence model describing the interaction relationships between subsystems, comprising: S10221. For each subsystem and its corresponding key business process, construct a SysML activity diagram describing its internal behavioral logic and a SysML sequence diagram describing the interaction protocol between them. S10222. Integrate the activity model and the sequence model to construct the functional architecture model of the automotive safety sandbox regulatory cloud platform.

[0030] In steps S10221-S10222, this application analyzes the responsibilities of each subsystem, such as "ensuring the validity, integrity, and consistency of the data entering the database," and decomposes its core activities, such as: receiving data, performing integrity checks, performing format checks, evaluating quality scores, generating quality reports, and providing feedback on quality results. The activity logic and process control are defined to obtain one (or more) SysML / UML activity diagrams, which constitute the construction of the activity model. The activity diagrams define the sequence of actions, decision nodes, and data flows that the subsystem performs to fulfill its responsibilities. For key business processes involving multiple subsystems, all subsystems participating in the process are identified, and messages are drawn in chronological order to generate a SysML / UML sequence diagram, thus constructing a sequence model. The sequence model defines the events triggered, services called, and messages passed between the subsystems in the time dimension through the sequence diagram. It also links the messages in the sequence diagram with the calling behavior actions or receiving event actions in the activity diagram. The output data generated in the activity diagram is associated with the data passed as parameters in the sequence diagram, and operations such as consistency checks, elimination of behavior conflicts, and filling in gaps are performed. All activity models (multiple activity diagrams) and sequence models (multiple sequence diagrams) that pass the consistency check are stored as a group of interrelated model elements in the same model repository or project model, thus constructing the functional architecture model. The functional architecture model includes the subsystem behavior logic defined by the activity diagram and the interaction protocol between subsystems defined by the sequence diagram.

[0031] In step S103, this application switches to the logical architecture design stage and the physical architecture design stage. Using the activity model and sequence model included in the functional architecture model, the logical architecture and physical architecture of the automotive safety sandbox regulatory cloud platform are designed separately, resulting in a logical architecture model and a physical architecture model. The logical architecture model maps dynamic behavioral processes to static structural units and their connections, while the physical architecture model transforms the technology-independent logical design into a technology-related implementation scheme. Specifically, behavioral carriers are abstracted into logical components (such as operation management, data access, data management, etc.), and based on the interaction protocol described by the sequence model, collaborative interfaces between components are defined, using a module definition diagram (such as...). Figure 7 (as shown) and internal module diagram (as shown) Figure 8 The logical architecture model is constructed as shown. The platform data acquisition module supports two methods: basic data entry and attachment upload (e.g., ...). Figure 7 , Figure 8As shown in the diagram, this is to accommodate the data submission habits of different enterprises. In the physical architecture design, for the logical components in the logical architecture model that correspond to the risk identification scenario, physical instantiation is defined through a deployment diagram, clarifying their software algorithm modules and deployment nodes, and establishing parameter constraint relationships between components, which together with the physical instantiation definition constitute the physical architecture model.

[0032] In the specific implementation of step S103, one embodiment is as follows: a logical architecture model is designed using a module definition diagram and an internal module diagram, and a physical architecture model is designed using a parameter diagram and a deployment diagram, including: S1031. Configure the corresponding model building method based on SysML language according to the characteristics of the logical architecture and the physical architecture respectively; S1032. Execute the model construction method to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform respectively.

[0033] In steps S1031-S1032, this application configures corresponding model construction methods based on the characteristics of the logical architecture and physical architecture, respectively. The logical architecture requires top-level system decomposition, interface identification and definition, component refinement and interface allocation, and recursive decomposition. The physical architecture requires technology selection and artifact definition, including parameterized modeling with parameter constraints, node definition domain deployment and allocation, and communication and resource configuration. The model construction methods corresponding to the logical architecture and physical architecture are executed respectively to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform. By configuring completely different model construction methods for the logical and physical architectures, logical architecture models and physical architecture models with different abstraction levels but close relationships are obtained. Using the parameter graph in the physical architecture model, the non-functional requirements identified in the logical architecture stage can be quantitatively analyzed and simulated for verification. When a certain technology needs to be changed (such as changing from RESTful API to gRPC), all affected artifacts and connections can be clearly located in the physical architecture model, and the impact on logical interface definitions and performance parameters can be evaluated.

[0034] In a specific implementation of step S1032, one embodiment involves: executing the model construction method to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform, including: A1. Based on the behavioral logic described in the activity model, the behavioral carrier is abstracted into a logical component with static responsibilities; A2. Based on the interaction protocol described by the sequence model, define the collaboration interface between the logical components, and formally describe the logical components and collaboration interface through a module definition diagram to construct a logical architecture model.

[0035] In steps A1-A2, this application switches from the functional architecture design phase to the logical architecture design phase. In this phase, based on the functional requirements of each subsystem, including defining the interfaces and interaction methods between components, and the data flow and message passing between systems, an object-oriented modeling method is used to deconstruct the functional elements and coupling rules of the automotive safety sandbox monitoring cloud platform. Based on the behavioral logic described by the activity model, the behavioral carriers are abstracted into logical components with static responsibilities. Four logical components are established: operation management, data access, data management, and data application. The static responsibilities of each logical component are defined, and the model is drawn... Figure 7 The system module definition diagram shown describes the hierarchical relationship of the top-level system; the subsystem inputs in the design process are optimized, the interface definitions of key subsystems of the cloud platform are improved, and the collaboration interfaces between the logical components are defined according to the interaction protocol described by the sequence model. The collaboration interfaces include interface names, data types transmitted, and call timing constraints. The logical components and their collaboration interfaces are formally described through the module definition diagram to form the logical architecture model of the automotive safety sandbox supervision cloud platform.

[0036] like Figure 8 The internal module diagram shown defines the ports and interaction interfaces of the subsystems. Taking the safety supervision of the No-Action (NOA) driver assistance function as an example, enterprises conduct sandbox tests such as intelligent driving domain controllers and upload the test data to the data management module of the automotive safety sandbox supervision cloud platform for storage. External data providers provide real vehicle-reported data, such as driving trajectories and vehicle-side perception data, as well as cloud-reported data, such as map information. The data management module stores the reported data and provides feedback on data quality. The data application module can analyze and mine specified data to identify NOA safety technology risks, such as whether it has driver hands-off detection function, risk avoidance capability in extreme situations, and the ability to identify and respond to complex scenarios. Safety risk information is managed in the operation management module and fed back to the enterprise. The data application module also has data display capabilities and data service capabilities for market supervision and other departments. The operation management module has the ability to manage enterprise management and external data services.

[0037] In a specific implementation of step A2, one embodiment is as follows: After defining the collaboration interfaces between the logical components and formally describing the logical components and collaboration interfaces through a module definition diagram to construct a logical architecture model, the following steps are included: B1. For the logical components in the logical architecture model that correspond to the automotive safety risk identification scenario, physical instantiation is defined through a deployment diagram; B2. The parameter constraint relationship of the logical components is established through the parameter diagram, which together with the physical instantiation definition constitutes the physical architecture model of the automotive safety sandbox regulatory cloud platform.

[0038] In steps B1-B2, this application switches from the logical architecture design stage to the physical architecture design stage. In this stage, the entity class parameters of the subsystem are defined and configured, the information space class algorithm module is decomposed and the interface is defined, and the algorithm code framework is built. Thus, for the logical components in the logical architecture model corresponding to the automotive safety risk identification scenario, physical instantiation is defined. The physical instantiation definition includes: determining the software algorithm module, deployment node and configuration parameters that implement the component; balancing different configuration schemes of the system architecture of the automotive safety sandbox regulatory cloud platform by establishing parameter diagrams corresponding to parameter constraint relationships; for the risk identification algorithm module, defining its input parameters, output parameters and internal calculation parameters, and establishing mathematical or logical constraint relationships between the parameters through parameter diagrams; and formally describing the physical instantiation definition and parameter constraint relationships through deployment diagrams and parameter diagrams to constitute the physical architecture model of the automotive safety sandbox regulatory cloud platform.

[0039] In step S104, this application switches to the simulation verification and optimization stage. In this stage, a semantically consistent and executable system model of the automotive safety sandbox regulatory cloud platform is integrated based on the requirements model, functional architecture model, logical architecture model, and physical architecture model. Different code generation strategies are configured according to the simulation objectives, and executable code is generated and simulated for testing. The simulation testing is conducted using simulation test cases configured based on the business scenarios defined in the requirements model and use case model. These business scenarios include normal business process simulation, abnormal data simulation, high-risk scenario simulation, and performance stress simulation. Simulation tools such as Matlab / Simulink or Cameo Simulation Toolkit are used for implementation. Figure 9 As shown, if the simulation test passes, the automotive safety sandbox monitoring cloud platform can be directly established. If it fails, the system model is iteratively optimized based on the data obtained from the simulation test to locate defects and performance bottlenecks before the automotive safety sandbox monitoring cloud platform is established. This early simulation verification can significantly shorten the development cycle, reduce repair costs, and improve the rationality and accuracy of the system architecture.

[0040] Example 2 This application also provides an MBSE-based automotive safety sandbox monitoring device, such as... Figure 10 The diagram shows a block diagram of an MBSE-based automotive safety sandbox monitoring device. The functions implemented by this MBSE-based automotive safety sandbox monitoring device correspond to the steps described above in executing an MBSE-based automotive safety sandbox monitoring method on a terminal device. This device can be understood as a server component including a processor. The MBSE-based automotive safety sandbox monitoring device described in this application includes: Analysis module 1001 is used to perform system requirements analysis based on the business scenarios of the automotive safety sandbox. It uses SysML language to construct a requirement model that reflects the hierarchical relationship of requirements and a use case model that reflects the interaction between the automotive safety sandbox supervision cloud platform and external roles. The decomposition module 1002 is used to decompose the functions of the automotive safety sandbox regulatory cloud platform and allocate them to different subsystems based on the requirement model and the use case model. It constructs a functional architecture model that includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocol between the subsystems through SysML activity diagrams and sequence diagrams. Design module 1003 is used to design a logical architecture model for the automotive safety sandbox regulatory cloud platform using module definition diagrams and internal module diagrams, and to design a physical architecture model using parameter diagrams and deployment diagrams, based on the functional architecture model. The integration module 1004 is used to generate executable code and perform simulation tests on the system model of the automotive safety sandbox regulatory cloud platform, which is integrated based on the requirement model, functional architecture model, logical architecture model and physical architecture model, in order to identify design defects and perform iterative optimization.

[0041] In one feasible implementation, the design module includes: Configure corresponding SysML-based model building methods based on the characteristics of the logical architecture and physical architecture respectively; The model building method described above is executed to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform, respectively.

[0042] In one feasible implementation, the design module further includes: Based on the behavioral logic described in the activity model, the behavioral carrier is abstracted into a logical component with static responsibilities; Based on the interaction protocol described by the sequence model, the collaboration interface between the logical components is defined, and the logical components and collaboration interface are formally described through a module definition diagram to construct a logical architecture model. In one feasible implementation, the design module also includes: For the logical components in the aforementioned logical architecture model that correspond to the automotive safety risk identification scenario, physical instantiation is defined using a deployment diagram; The parameter constraints of the logical components are established through the parameter graph, which together with the physical instantiation definition constitute the physical architecture model of the automotive safety sandbox regulatory cloud platform.

[0043] In one feasible implementation, the decomposition module includes: For each subsystem and its corresponding key business process, a SysML activity diagram describing its internal behavioral logic and a SysML sequence diagram describing the interaction protocol between them are constructed respectively. The activity model and the sequence model are integrated to construct the functional architecture model of the automotive safety sandbox regulatory cloud platform.

[0044] In one feasible implementation, the decomposition module further includes: High-level functional goals are mapped from the requirements model, and key interactive behaviors are identified from the use case model, respectively. Cross-analysis and merging of the high-level functional objectives and the key interactive behaviors form a list of functional characteristics to obtain the functional decomposition results.

[0045] In one feasible implementation, the analysis module includes: The original requirements in the field of automotive safety sandbox supervision are obtained in a structured manner, and the original requirements are analyzed and classified in a structured way. The requirements are expressed in a hierarchical graphical model to obtain the requirement model. Based on the aforementioned requirements model and stakeholder analysis, all external participant roles that need to interact are identified and corresponding use cases are defined to construct a use case model.

[0046] Example 3 This application also provides an electronic device, such as Figure 11 As shown, it includes: a processor 1101, a memory 1102, and a bus 1103. The memory 1102 stores machine-readable instructions that can be executed by the processor 1101. When the electronic device is running, the processor 1101 and the memory 1102 communicate with each other through the bus 1103. When the machine-readable instructions are executed by the processor 1101, they perform the steps of any of the MBSE-based automotive safety sandbox monitoring methods described above.

[0047] Example 4 This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of any of the MBSE-based automotive safety sandbox monitoring methods described in the present invention.

[0048] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0049] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0050] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0051] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0052] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for supervising a car safety sandbox based on MBSE, characterized in that, The method includes: Based on the business scenario of automotive safety sandbox supervision, system requirements analysis is conducted, and a requirement model reflecting the hierarchical relationship of requirements and a use case model reflecting the interaction relationship between the automotive safety sandbox supervision cloud platform and external roles are constructed using the SysML language. Based on the aforementioned requirement model and use case model, the functions used in the automotive safety sandbox regulatory cloud platform are decomposed and allocated to different subsystems. Using SysML activity diagrams and sequence diagrams, a functional architecture model is constructed, which includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocols between the subsystems. Based on the aforementioned functional architecture model, the logical architecture model of the automotive safety sandbox regulatory cloud platform is designed using module definition diagrams and internal module diagrams, and the physical architecture model is designed using parameter diagrams and deployment diagrams. Based on the system model of the automotive safety sandbox regulatory cloud platform, which integrates the aforementioned requirement model, functional architecture model, logical architecture model, and physical architecture model, executable code is generated and simulation tests are performed to identify design defects and conduct iterative optimization.

2. The method according to claim 1, characterized in that, A logical architecture model is designed using module definition diagrams and internal module diagrams, and a physical architecture model is designed using parameter diagrams and deployment diagrams, including: Configure corresponding SysML-based model building methods based on the characteristics of the logical architecture and physical architecture respectively; The model building method described above is executed to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform, respectively.

3. The method according to claim 2, characterized in that, The model building method described above is executed to construct the logical architecture model and physical architecture model of the automotive safety sandbox regulatory cloud platform, respectively, including: Based on the behavioral logic described in the activity model, the behavioral carrier is abstracted into a logical component with static responsibilities; Based on the interaction protocol described by the sequence model, the collaboration interface between the logical components is defined, and the logical components and collaboration interface are formally described through a module definition diagram to construct a logical architecture model.

4. The method according to claim 3, characterized in that, After defining the collaboration interfaces between the logical components and formally describing the logical components and collaboration interfaces through a module definition diagram to construct the logical architecture model, the following steps are included: For the logical components in the aforementioned logical architecture model that correspond to the automotive safety risk identification scenario, physical instantiation is defined using a deployment diagram; The parameter constraints of the logical components are established through the parameter graph, which together with the physical instantiation definition constitute the physical architecture model of the automotive safety sandbox regulatory cloud platform.

5. The method according to claim 1, characterized in that, The functional architecture model that constructs an activity model describing the behavior of subsystems and a sequence model describing the interaction relationships between subsystems includes: For each subsystem and its corresponding key business process, a SysML activity diagram describing its internal behavioral logic and a SysML sequence diagram describing the interaction protocol between them are constructed respectively. The activity model and the sequence model are integrated to construct the functional architecture model of the automotive safety sandbox regulatory cloud platform.

6. The method according to claim 1, characterized in that, Based on the demand model and the use case model, the functions of the automotive safety sandbox supervision cloud platform for automotive safety sandbox supervision are decomposed, including: High-level functional goals are mapped from the requirements model, and key interactive behaviors are identified from the use case model, respectively. Cross-analyze and merge the high-level functional objectives and the key interactive behaviors to form a list of functional characteristics, thereby obtaining the functional decomposition results.

7. The method according to claim 1, characterized in that, A requirement model reflecting the hierarchical relationships of requirements and a use case model reflecting the interaction between the automotive safety sandbox regulatory cloud platform and external roles are constructed using the SysML language, including: The original requirements in the field of automotive safety sandbox supervision are obtained in a structured manner, and the original requirements are analyzed and classified in a structured way. The requirements are expressed in a hierarchical graphical model to obtain the requirement model. Based on the aforementioned requirements model and stakeholder analysis, all external participant roles that need to interact are identified and corresponding use cases are defined to construct a use case model.

8. A vehicle safety sandbox monitoring device based on MBSE, characterized in that, The device includes: The analysis module is used to perform system requirements analysis based on the business scenarios of automotive safety sandbox supervision. It uses SysML language to construct a requirement model that reflects the hierarchical relationship of requirements and a use case model that reflects the interaction relationship between the automotive safety sandbox supervision cloud platform and external roles. The decomposition module is used to decompose the functions of the automotive safety sandbox regulatory cloud platform based on the requirement model and the use case model and allocate them to different subsystems. It constructs a functional architecture model that includes an activity model describing the internal behavioral logic of the subsystems and a sequence model describing the interaction protocol between the subsystems through SysML activity diagrams and sequence diagrams. The design module is used to design the logical architecture model of the automotive safety sandbox regulatory cloud platform using module definition diagrams and internal module diagrams, and to design the physical architecture model using parameter diagrams and deployment diagrams, based on the functional architecture model. An integration module is used to generate executable code and perform simulation tests on the system model of the automotive safety sandbox regulatory cloud platform, which is integrated based on the aforementioned requirement model, functional architecture model, logical architecture model, and physical architecture model, in order to identify design defects and perform iterative optimization.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of an MBSE-based automotive safety sandbox regulatory method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of an MBSE-based automotive safety sandbox regulatory method as described in any one of claims 1 to 7.

Images