System architecture design method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a system architecture design method and device, electronic equipment and a storage medium. Acquiring system requirements of a to-be-designed system; determining feature elements according to system requirements, and creating a requirement analysis model for decomposing the system requirements through a graphical modeling language; distributing each feature element to a corresponding target component through a demand analysis model to obtain a target component model; and performing simulation verification on the target component model, and updating the corresponding target component model through difference analysis when the verification result is that the demand is not realized. According to the embodiment of the invention, the workload of system architecture development is reduced, and the development period is shortened.

Description

Technical Field

[0001] The embodiments of the present application relate to electronic and electrical technologies, and in particular, to a system architecture design method, device, electronic device and storage medium. Background Art

[0002] The electronic and electrical system in a vehicle is an important component of the vehicle. Therefore, the design of the electronic and electrical system is an important component in the design of the vehicle system.

[0003] In the prior art, after an electronic and electrical system is developed according to requirements, functional level testing and verification are usually performed according to the requirement specification document to determine whether the system architecture of the designed electronic and electrical system meets the requirements.

[0004] However, if the requirements verification fails after development, the design and development process of the entire system architecture will need to be re-proofread, which will increase the workload of system architecture development and extend the development cycle of the entire development cycle. Summary of the invention

[0005] The present application provides a system architecture design method, device, electronic device and storage medium to reduce the workload of system architecture development and shorten the development cycle.

[0006] In a first aspect, an embodiment of the present application provides a system architecture design method, which is applied to an electronic and electrical development system. The system architecture design method includes:

[0007] Obtain system requirements for the system to be designed;

[0008] Determine characteristic elements according to system requirements, and create a demand analysis model that decomposes system requirements through a graphical modeling language;

[0009] Allocate each characteristic element to the corresponding target component through the demand analysis model to obtain the target component model;

[0010] The target component model is simulated and verified, and when the verification result shows that the requirement is not met, the corresponding target component model is updated through difference analysis.

[0011] In a second aspect, the embodiment of the present application further provides a system architecture design device, which is configured in an electronic and electrical development system, and the system architecture design device includes:

[0012] System requirement acquisition module, used to obtain system requirements of the system to be designed;

[0013] A requirement analysis model creation module is used to determine characteristic elements according to system requirements and create a requirement analysis model for decomposing system requirements through a graphical modeling language;

[0014] A target component model obtaining module is used to allocate each characteristic element to a corresponding target component through a demand analysis model to obtain a target component model;

[0015] The target component model update module is used to simulate and verify the target component model, and when the verification result is that the requirement is not met, update the corresponding target component model through difference analysis.

[0016] In a third aspect, an embodiment of the present application further provides an electronic device, the electronic device comprising:

[0017] one or more processors;

[0018] A storage device for storing one or more programs;

[0019] When one or more programs are executed by one or more processors, the one or more processors implement any system architecture design method provided in the embodiments of the present application.

[0020] In a fourth aspect, an embodiment of the present application further provides a storage medium comprising computer executable instructions, which, when executed by a computer processor, are used to execute any system architecture design method provided in an embodiment of the present application.

[0021] The present application obtains the system requirements of the system to be designed; determines the characteristic elements according to the system requirements, and creates a demand analysis model for decomposing the system requirements through a graphical modeling language; assigns each characteristic element to the corresponding target component through the demand analysis model, obtains the target component model, refines the requirements, and is convenient for checking the difference points when the subsequent verification result is that the requirements are not realized; simulates and verifies the target component model, and when the verification result is that the requirements are not realized, updates the corresponding target component model through difference analysis, verifies the requirements in the process of system architecture design, timely finds the difference between the functions implemented by the target component model and the system requirements, adjusts the target component model, ensures that the designed target component model can meet the system requirements, reduces the modification workload of the subsequent development process, and because the difference is found in the early stage of design, the later development does not need to be repeatedly modified due to unsatisfied requirements, shortens the development cycle. Therefore, through the technical solution of the present application, the problem that when the demand verification fails after development, the design and development process of the entire system architecture needs to be re-proofread, the workload of system architecture development is increased, and the development cycle is extended is solved, and the workload of system architecture development is reduced and the development cycle is shortened. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a flow chart of a system architecture design method in Embodiment 1 of the present application;

[0023] Figure 2 It is a flow chart of a system architecture design method in Embodiment 2 of the present application;

[0024] Figure 3 It is a structural diagram of a system architecture design device in Embodiment 3 of the present application;

[0025] Figure 4 It is a structural diagram of an electronic device in Embodiment 4 of the present application. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first" and "second" etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] Embodiment 1

[0029] Figure 1 A flowchart of a system architecture design method provided in Embodiment 1 of the present application. This embodiment is applicable to the development, design and simulation verification of electronic and electrical systems. The method can be executed by a system architecture design device, which can be implemented in software and / or hardware and specifically configured in an electronic and electrical development system, for example, an electronic and electrical system development platform.

[0030] See also Figure 1 The system architecture design method shown is applied to the electronic and electrical development system and specifically includes the following steps:

[0031] S110. Obtain system requirements of the system to be designed.

[0032] The system requirements may be the design requirements of the entire system to be designed, which are used to determine the functions that the system to be designed needs to implement, and then design the corresponding system architecture. The system to be designed is also the electronic and electrical system that needs to be designed. For example, the system to be designed may be the electronic and electrical system in a vehicle system.

[0033] In an optional embodiment, the system requirements in the vehicle include at least: vehicle requirements, vehicle-related requirements and third-party requirements. Vehicle-related requirements may be requirements associated with the vehicle system. Exemplarily, when the vehicle requirements are charging system requirements, the corresponding vehicle-related requirements may be charging pile requirements. For example, the charging pile requirements may include interface protocols and charging voltage requirements. Third-party requirements may be requirements of a third party other than vehicle requirements and vehicle-related requirements. For example, third-party requirements may include relevant specification requirements and user requirements.

[0034] For example, system requirements can be imported in word (professional term, a file format), excel (professional term, a file format) or txt (professional term, a file format), or directly manually create requirements in rhapsody (professional term, a model-driven visual development software) as an element for subsequent creation of a requirements analysis model. Optionally, system requirements can be managed through specific software, and changes to system requirements can be stored to ensure the traceability of requirements and facilitate verification of 100% realization of requirements.

[0035] S120. Determine characteristic elements according to system requirements, and create a requirement analysis model for decomposing system requirements through a graphical modeling language.

[0036] Characteristic elements can be the implementation elements of system requirements and are used to build a demand analysis model. Exemplarily, characteristic elements can include operations, events, and data flows. A system use case diagram can be created through a graphical modeling language for demand analysis. Exemplarily, the graphical modeling language can be a sysml (professional term, a graphical modeling language) language, and the analysis model of the system can be created accordingly using activity diagrams or timing diagrams in the sysml language according to system characteristics. The demand analysis model is used to decompose system requirements in order to assign each characteristic element to the corresponding target component.

[0037] S130. Allocate each characteristic element to a corresponding target component through the demand analysis model to obtain a target component model.

[0038] The target component can be each functional component that realizes the system requirements. The required target components can be determined through demand analysis, and each characteristic element can be assigned to the corresponding target component to obtain the target component model. The target component model is also the system framework for realizing the system requirements, which is composed of each target component and the characteristic elements corresponding to each target component. Specifically, the demand analysis model can refine the system requirements into multiple subsystems through demand analysis; for the system requirements corresponding to each subsystem, further refine the requirements, subdivide the system requirements corresponding to the subsystem into components, and assign each characteristic element to the corresponding target component, and perform different architecture designs according to the system characteristics of the subsystem to obtain the target component model. System characteristics can include timing and state. For example, when the system characteristics in the subsystem are timing, the target component model is designed through a timing diagram; when the system characteristics in the subsystem are state, the target component model is designed through an activity diagram.

[0039] S140, performing simulation verification on the target component model, and when the verification result shows that the requirement is not met, updating the corresponding target component model through difference analysis.

[0040] According to the type of target component model, create a simulation scenario and perform simulation verification. The specific simulation verification can complete the corresponding simulation process according to the characteristics of the simulation software. For example, when performing simulation verification through rhapsody software, for the target component model created based on the activity diagram, you can directly generate an execution scenario for simulation, and get the verification result based on whether it meets the requirements. For the target component model created based on the timing diagram, it needs to be converted into a state diagram before simulation, and the timing diagram after simulation is compared with the target component model to get the verification result.

[0041] When the verification result is that the requirements are met, it means that there is no problem with the current system design, the design of the system requirements has been completed, and it can be delivered to the downstream to guide development work; when the verification result is that the requirements are not met, it means that there are problems with the current system design and the design of the system requirements has not been completed. In this case, it is necessary to re-analyze the unsatisfied execution scenarios to supplement the requirements or update the system model. Difference analysis is to analyze the target component model in the execution scenarios that do not meet the corresponding system requirements, specifically analyzing the target components that cause the differences, which are used to update the corresponding target component model, or supplement the requirements when other system requirements are required.

[0042] In the prior art, the system development process is as follows: engineers write a system requirement description document based on the system requirements proposed by the whole vehicle, and then design the system hardware and software based on the system description document. After development, functional level testing and verification are performed according to the requirement description document, and then system level integration testing and verification are performed according to the system requirements. Development is completed after verification.

[0043] However, at present, most people use documents such as Excel or Word to design electronic and electrical systems, and then communicate various information in the project through documents. With the increasing complexity of vehicle systems and the possible ambiguity of documents, there are differences between the developed products and the products required by users, and there is no good way to identify these differences and verify the correctness of the design in the early stages of system development, which leads to extended development cycles and increased development workload.

[0044] The technical solution of this embodiment is to obtain the system requirements of the system to be designed; determine the characteristic elements according to the system requirements, and create a demand analysis model for decomposing the system requirements through a graphical modeling language; assign each characteristic element to the corresponding target component through the demand analysis model, obtain the target component model, refine the requirements, and facilitate the subsequent verification result to check the difference points when the verification result is that the requirements are not realized; simulate and verify the target component model, and when the verification result is that the requirements are not realized, update the corresponding target component model through difference analysis, perform demand verification in the process of system architecture design, timely find the difference between the functions implemented by the target component model and the system requirements, adjust the target component model, ensure that the designed target component model can meet the system requirements, reduce the modification workload of the subsequent development process, and because the difference is found in the early stage of design, the later development does not need to be repeatedly modified due to unsatisfied requirements, shortening the development cycle. Therefore, through the technical solution of this application, when the demand verification fails after development, the design and development process of the entire system architecture needs to be re-proofread, which increases the workload of system architecture development and prolongs the development cycle, and achieves the effect of reducing the workload of system architecture development and shortening the development cycle.

[0045] Embodiment 2

[0046] Figure 2 This is a flow chart of a system architecture design method provided in Example 2 of the present application. The technical solution of this embodiment is further refined on the basis of the above technical solution.

[0047] Furthermore, "assign each characteristic element to the corresponding target component through the requirement analysis model to obtain the target component model" is refined as: "According to the system logical functional requirements, decompose the system requirements through the requirement analysis model to obtain the subsystem requirements, and determine the characteristic elements corresponding to each subsystem requirement; according to each subsystem requirement, determine the target component of each subsystem requirement, and assign the characteristic elements corresponding to the subsystem requirements to the target component to obtain the target component model" to obtain the target component model.

[0048] See also Figure 2 A system architecture design method shown includes:

[0049] S210, obtaining system requirements of the target component model.

[0050] S220. Determine characteristic elements according to system requirements, and create a requirement analysis model for decomposing system requirements through a graphical modeling language.

[0051] S230. According to the system logical function requirements, the system requirements are decomposed through the requirements analysis model to obtain subsystem requirements, and the characteristic elements corresponding to each subsystem requirement are determined.

[0052] According to the logical functional requirements in the requirement analysis model, the system requirements can be decomposed into multiple subsystem requirements, that is, the system can be decomposed into multiple subsystems. Accordingly, the system requirements are allocated to the corresponding subsystems to obtain the subsystem requirements.

[0053] Requirements analysis can include the definition, decomposition and allocation of requirements. By performing requirements analysis through the requirements analysis model, the system requirements can be refined and allocated to each subsystem, and the system requirements can be decomposed to obtain the subsystem requirements, and then characteristic elements can be allocated. By decomposing the system requirements according to the system logical functions to obtain subsystems, the functional logical consistency of each subsystem can be guaranteed. Exemplarily, when the requirements analysis model is a system use case diagram, characteristic elements can be allocated to the subsystems according to the use case behaviors in the system use case diagram, that is, the characteristic elements corresponding to the requirements of each subsystem can be determined. Exemplarily, the relationship between the system and the subsystem can be reflected by creating an internal block diagram in the sysml language.

[0054] S240. Determine the target component of each subsystem requirement according to the requirements of each subsystem, and assign characteristic elements corresponding to the requirements of the subsystem to the target component to obtain a target component model.

[0055] After dividing each subsystem and obtaining the corresponding requirements of each subsystem, further demand analysis is performed on the subsystem to subdivide the subsystem requirements into functional components. For example, an activity diagram or sequence diagram in the sysml language can be used to create a behavioral analysis model between components, and the subsystem requirements are refined and assigned to each component, and the characteristic elements corresponding to the subsystem requirements are assigned to the target component to obtain the target component model.

[0056] In an optional embodiment, characteristic elements corresponding to the requirements of the subsystem to which it belongs are assigned to the target component to obtain a target component model, including: creating a component analysis model for analyzing the behavior between the target components through an activity diagram or a timing diagram; and assigning the characteristic elements corresponding to the requirements of the subsystem to the corresponding target component through the component analysis model to obtain a target component model.

[0057] Activity diagram is a kind of diagram in sysml language, which is used to analyze the behavior between target components, focusing on expressing the control flow and signal flow from input to output through a series of actions, and is an analysis tool for understanding system requirements. Sequence diagram is another kind of diagram in sysml language, which is used to analyze the behavior between target components, focusing on the interaction with another module through operation calls and asynchronous signals, and is a good way to refine test cases.

[0058] Determine whether to use an activity diagram or a sequence diagram based on the system characteristics of the subsystem corresponding to the subsystem requirements. Create a component analysis model for analyzing the behaviors between target components through activity diagrams or sequence diagrams. Through the component analysis model, assign the characteristic elements corresponding to the requirements of the subsystem to the corresponding target components to obtain the target component model.

[0059] Through activity diagrams or timing diagrams, create a component analysis model for analyzing the behaviors between target components. Through the component analysis model, assign the characteristic elements corresponding to the requirements of the subsystem to the corresponding target components to obtain a target component model. The characteristic elements corresponding to the requirements of the subsystem are refined to each target component to achieve the refinement of system requirements at the component level and ensure the realization of system requirements.

[0060] S250, performing simulation verification on the target component model, and when the verification result shows that the requirement is not met, updating the corresponding target component model through difference analysis.

[0061] In an optional embodiment, if a component analysis model for analyzing the behavior between target components is created through an activity diagram, the target component model is simulated and verified, including: determining an execution scenario based on the target component model; and simulating and verifying the target component model in the execution scenario to achieve verification of the target component model.

[0062] The execution scenario can be a scenario for simulating the component analysis model. In the case of using activity diagrams to create component analysis models, a specific execution scenario can be generated in the Rhapsody software for activity diagrams that contain complete operations, events, and data flows. In the execution scenario, the target component model can be simulated and verified to verify whether the currently created component analysis model meets the requirements, thereby achieving verification of the target component model.

[0063] By creating a component analysis model that analyzes the behaviors between target components through activity diagrams, the execution scenario is determined based on the target component model. In the execution scenario, the target component model is simulated and verified to verify whether the target component model has achieved the corresponding subsystem requirements. When it cannot be realized, it is corrected in time to find the differences and ensure that the system architecture design can achieve the system requirements.

[0064] In an optional embodiment, if a component analysis model for analyzing the behavior between target components is created through a timing diagram, the target component model is simulated and verified, including: determining an execution scenario based on the target component model; creating an execution state diagram in the execution scenario, and adding characteristic elements corresponding to the target component model to the execution state diagram; simulating the execution state diagram to obtain an execution timing diagram to verify the target component model.

[0065] In the case of using a sequence diagram to create a component analysis model, verification in the Rhapsody software is more complicated. First, determine the execution scenario based on the target component model. Create a state diagram in the SysML language based on the execution scenario in the Rhapsody software to obtain the execution state diagram. After updating the characteristic elements to the execution state diagram, the execution state diagram can automatically generate an execution sequence diagram to verify the target component model. Compare the execution sequence diagram with the target component model. If there is no difference, it means that there is no problem with the current system design. The completed system design can be delivered to the downstream to guide development work; if there are differences, the differences need to be analyzed in detail later to supplement the requirements or update the target component model.

[0066] By creating a component analysis model that analyzes the behavior between target components through a timing diagram, the execution scenario is determined according to the target component model; an execution state diagram is created in the execution scenario, and the characteristic elements corresponding to the target component model are added to the execution state diagram; the execution state diagram is simulated to obtain an execution timing diagram, and the target component model is verified. The target component model created based on the timing diagram is verified to verify whether the verification of the target component model realizes the corresponding subsystem requirements. When it cannot be realized, it is corrected in time to find the differences and ensure that the system architecture design can realize the system requirements.

[0067] The technical solution of this embodiment is to decompose the system requirements through the requirement analysis model according to the system logical function requirements, obtain the subsystem requirements, and determine the characteristic elements corresponding to each subsystem requirement; according to each subsystem requirement, determine the target component of each subsystem requirement, and assign the characteristic elements corresponding to the subsystem requirements to the target component to obtain the target component model, gradually decompose the system requirements, refine them to components, and assign characteristic elements, thereby realizing the system architecture design and ensuring the accurate realization of system requirements.

[0068] Embodiment 3

[0069] Figure 3 The structure diagram of a system architecture design device provided in the third embodiment of the present application is shown. This embodiment can be applied to the case of developing, designing and simulating and verifying an electronic and electrical system, and can be configured on an electronic and electrical system development platform. The specific structure of the system architecture design device is as follows:

[0070] The system requirement acquisition module 310 is used to acquire the system requirements of the system to be designed;

[0071] A requirement analysis model creation module 320 is used to determine characteristic elements according to system requirements and create a requirement analysis model for decomposing system requirements through a graphical modeling language;

[0072] The target component model obtaining module 330 is used to allocate each characteristic element to the corresponding target component through the demand analysis model to obtain the target component model;

[0073] The target component model updating module 340 is used to perform simulation verification on the target component model, and when the verification result is that the requirement is not met, update the corresponding target component model through difference analysis.

[0074] The technical solution of this embodiment is to obtain the system requirements of the system to be designed; determine the characteristic elements according to the system requirements, and create a demand analysis model for decomposing the system requirements through a graphical modeling language; assign each characteristic element to the corresponding target component through the demand analysis model, obtain the target component model, refine the requirements, and facilitate the subsequent verification result to check the difference points when the verification result is that the requirements are not realized; simulate and verify the target component model, and when the verification result is that the requirements are not realized, update the corresponding target component model through difference analysis, perform demand verification in the process of system architecture design, timely find the difference between the functions implemented by the target component model and the system requirements, adjust the target component model, ensure that the designed target component model can meet the system requirements, reduce the modification workload of the subsequent development process, and because the difference is found in the early stage of design, the later development does not need to be repeatedly modified due to unsatisfied requirements, shortening the development cycle. Therefore, through the technical solution of this application, when the demand verification fails after development, the design and development process of the entire system architecture needs to be re-proofread, which increases the workload of system architecture development and prolongs the development cycle, and achieves the effect of reducing the workload of system architecture development and shortening the development cycle.

[0075] Optionally, the target component model obtaining module 330 includes:

[0076] The system requirement decomposition unit is used to decompose the system requirements according to the system logical function requirements through the requirement analysis model, obtain the subsystem requirements, and determine the characteristic elements corresponding to each subsystem requirement;

[0077] The subsystem requirement decomposition unit is used to determine the target components of each subsystem requirement according to the requirements of each subsystem, and allocate characteristic elements corresponding to the requirements of the subsystem to the target component to obtain the target component model.

[0078] Optional, subsystem requirement decomposition unit, including:

[0079] A component analysis model creation subunit is used to create a component analysis model for analyzing the behaviors between target components through an activity diagram or a sequence diagram;

[0080] The characteristic element allocation subunit is used to allocate the characteristic elements corresponding to the requirements of the subsystem to the corresponding target components through the component analysis model to obtain the target component model.

[0081] Optionally, if a component analysis model for analyzing the behaviors between target components is created through an activity diagram, the target component model updating module 340 includes:

[0082] An execution scenario determination unit, used to determine an execution scenario according to a target component model;

[0083] The simulation verification unit is used to perform simulation verification on the target component model in the execution scenario to realize verification of the target component model.

[0084] Optionally, if a component analysis model for analyzing the behaviors between target components is created through a sequence diagram, the target component model updating module 340 includes:

[0085] An execution scenario determination unit, used to determine an execution scenario according to a target component model;

[0086] A state diagram determination unit, used to create an execution state diagram in an execution scenario, and add characteristic elements corresponding to the target component model to the execution state diagram;

[0087] The state diagram simulation unit is used to simulate the execution state diagram to obtain the execution sequence diagram and realize the verification of the target component model.

[0088] Optional, characteristic elements, including at least: operations, events and data flows.

[0089] The system architecture design device provided in the embodiment of the present application can execute the system architecture design method provided in any embodiment of the present application, and has the corresponding functional modules and beneficial effects for executing the system architecture design method.

[0090] Embodiment 4

[0091] Figure 4 A schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present application is shown in FIG. Figure 4 As shown, the electronic device includes a processor 410, a memory 420, an input device 430, and an output device 440; the number of the processor 410 in the electronic device can be one or more. Figure 4 A processor 410 is taken as an example; the processor 410, the memory 420, the input device 430 and the output device 440 in the electronic device can be connected via a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0092] The memory 420, as a computer-readable storage medium, can be used to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the system architecture design method in the embodiment of the present application (for example, the system requirement acquisition module 310, the requirement analysis model creation module 320, the target component model acquisition module 330 and the target component model update module 340). The processor 410 executes various functional applications and data processing of the electronic device by running the software programs, instructions and modules stored in the memory 420, that is, implements the above-mentioned system architecture design method.

[0093] The memory 420 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and at least one application required for a function; the data storage area may store data created according to the use of the terminal, etc. In addition, the memory 420 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 420 may further include a memory remotely arranged relative to the processor 410, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0094] The input device 430 may be used to receive input character information and generate key signal input related to user settings and function control of the electronic device. The output device 440 may include a display device such as a display screen.

[0095] According to an embodiment of the present invention, the present invention also provides an electronic device, a readable storage medium and a computer program product.

[0096] Embodiment 5

[0097] Embodiment 5 of the present application also provides a storage medium containing computer executable instructions, which, when executed by a computer processor, are used to execute a system architecture design method, which is applied to an electronic and electrical development system, and the method includes: obtaining system requirements of the system to be designed; determining characteristic elements according to the system requirements, and creating a requirement analysis model for decomposing the system requirements through a graphical modeling language; assigning each characteristic element to a corresponding target component through the requirement analysis model to obtain a target component model; simulating and verifying the target component model, and when the verification result is that the requirement is not met, updating the corresponding target component model through difference analysis.

[0098] Of course, the storage medium containing computer executable instructions provided in the embodiment of the present application, whose computer executable instructions are not limited to the method operations described above, can also execute related operations in the system architecture design method provided in any embodiment of the present application.

[0099] Through the above description of the implementation method, the technicians in the relevant field can clearly understand that the present application can be implemented with the help of software and necessary general hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application can be essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., including a number of instructions for an electronic device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0100] It is worth noting that in the embodiment of the above-mentioned system architecture design device, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application.

[0101] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present application, and the scope of the present application is determined by the scope of the appended claims.

Claims

1. A system architecture design method, characterized in that: Applications in electronic and electrical development systems, including: Obtain system requirements for the system to be designed; Determining characteristic elements according to the system requirements, and creating a requirement analysis model for decomposing the system requirements through a graphical modeling language; Allocate each characteristic element to a corresponding target component through the demand analysis model to obtain a target component model; The target component model is simulated and verified, and when the verification result shows that the requirement is not met, the corresponding target component model is updated through difference analysis.

2. The method according to claim 1, characterized in that The step of allocating each characteristic element to a corresponding target component through the demand analysis model to obtain a target component model includes: According to the system logical function requirements, the system requirements are decomposed through the requirements analysis model to obtain subsystem requirements, and characteristic elements corresponding to each subsystem requirement are determined; According to the requirements of each subsystem, a target component of each subsystem requirement is determined, and characteristic elements corresponding to the requirements of the subsystem are allocated to the target component to obtain a target component model.

3. The method according to claim 2, characterized in that The step of allocating characteristic elements corresponding to the requirements of the subsystem to which the target component belongs to obtain a target component model includes: Creating a component analysis model for analyzing behaviors between the target components through an activity diagram or a sequence diagram; Through the component analysis model, the characteristic elements corresponding to the requirements of the subsystem are allocated to the corresponding target components to obtain the target component model.

4. The method according to claim 3, characterized in that If a component analysis model for analyzing the behaviors between the target components is created through an activity diagram, the simulation verification of the target component model includes: Determining an execution scenario according to the target component model; In the execution scenario, the target component model is simulated and verified to achieve verification of the target component model.

5. The method according to claim 3, characterized in that: If a component analysis model for analyzing the behaviors between the target components is created through a timing diagram, the simulation verification of the target component model includes: Determining an execution scenario according to the target component model; Creating an execution state diagram in the execution scenario, and adding feature elements corresponding to the target component model to the execution state diagram; The execution state diagram is simulated to obtain an execution sequence diagram, thereby verifying the target component model.

6. The method according to claim 1, characterized in that The characteristic elements at least include: operations, events and data flows.

7. A system architecture design device, characterized in that: Configured in electronic and electrical development systems, including: System requirement acquisition module, used to obtain system requirements of the system to be designed; A requirement analysis model creation module, used to determine characteristic elements according to the system requirements, and to create a requirement analysis model for decomposing the system requirements through a graphical modeling language; A target component model obtaining module is used to allocate each characteristic element to a corresponding target component through the demand analysis model to obtain a target component model; The target component model updating module is used to perform simulation verification on the target component model, and when the verification result is that the requirement is not met, update the corresponding target component model through difference analysis.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the system architecture design method as described in any one of claims 1-6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the system architecture design method as described in any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the system architecture design method according to any one of claims 1 to 6 is implemented.

Images