Design method and device for vehicle electronic and electrical system requirements and storage medium
By adopting a model-based design method in vehicle electronic and electrical systems, the problems of poor consistency and difficulty in demand traceability are solved, the requirements definition efficiency and response cycle are improved, and higher normativeness and accuracy are achieved.
Patent Information
- Application Number
- CN202411221977.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-02
- Publication Date
- 2024-12-27
AI Technical Summary
The prior art has problems such as poor consistency and difficulty in tracing demand in vehicle electronic and electrical systems, resulting in low demand definition efficiency and long response cycle of vehicle electronic and electrical products to the market.
Using a model-based design method, we will model the input requirements, functional design requirements, functional module design requirements and physical component design requirements, and establish a use case model, sequence model and block definition model to ensure the standardization and traceability of the design.
It improves the standardization and demand definition efficiency of electronic and electrical system demand design, shortens the response cycle of the entire vehicle electronic and electrical products to the market, and avoids typos and module errors in paper documents.
Smart Images
Figure CN119203368A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of electronic and electrical technology, and in particular to a design method, device and storage medium for vehicle electronic and electrical system requirements. Background Art
[0002] As the trend of vehicle intelligence and networking deepens, advanced functions such as smart driving and smart cockpits continue to increase, and the popularity of wireless download (Over-The-Air technology, OTA) functions is increasing. All of the above functions require the development cycle of vehicle highlight functions and value-added functions to be shorter and the development quality to be higher. However, the current document-based demand design method has risks such as poor consistency and difficulty in demand tracing, resulting in low efficiency in demand definition and a long response cycle for vehicle electronic and electrical products to the market. Summary of the invention
[0003] The present invention provides a design method, device and storage medium for vehicle electronic and electrical system requirements to solve the problems of poor consistency and difficulty in demand tracing in the prior art, which lead to low efficiency in demand definition and long response cycle of vehicle electronic and electrical products to the market.
[0004] According to one aspect of the present invention, a method for designing vehicle electrical and electronic system requirements is provided, comprising:
[0005] Import input requirements related to target functions;
[0006] Identify functional use cases and transform the input requirements into functional design requirements through scenarios under the functional use cases;
[0007] Identify functional modules related to target functions and convert the functional design requirements into functional module design requirements;
[0008] Identify physical components related to the target function and convert the functional module design requirements into physical component design requirements.
[0009] Optionally, the identifying a functional use case and converting the input requirement into a functional design requirement through a scenario under the functional use case includes:
[0010] The "participant" model element, "use case" model element, "bounding box" model element and "association" model element in the use case diagram are set according to the input requirements to establish a use case model of the target function; wherein the "use case" model element is the relevant use of the target function, the "participant" model element is the participant of the use case of the target function, the "bounding box" model element is the target function of the vehicle, and the "association" model element is the relationship between the participant and the use case.
[0011] Optionally, the identifying functional use cases and converting the input requirements into functional design requirements through scenarios under the functional use cases further includes:
[0012] The “system boundary” model element, “lifeline” model element, “interaction operator” model element, event class “message” model element and operation class “message” model element in the first sequence diagram of the scenario setting under the functional use case are used to establish the first sequence model of the target function; wherein the “system boundary” model element is the participant of the target function use case, the “lifeline” model element is the target function of the vehicle, the event class “message” model element is the interaction between the participant and the vehicle, the operation class “message” model element is the action of the vehicle, and the “interaction operator” model element is the mainstream and branch of the scenario.
[0013] Optionally, the identifying a functional module related to the target function and converting the functional design requirement into a functional module design requirement includes:
[0014] Based on the target function, M functional modules related to the target function are identified; wherein M is an integer greater than or equal to 1;
[0015] The "block" model elements and the "directional combination" model elements in the first block definition diagram are set according to the M functional modules to establish a first block definition model of the functional modules; wherein the "block" model elements are the target function and the M functional modules, and the "directional combination" model elements are the composition relationship between the target function and the M functional modules.
[0016] Optionally, the identifying a functional module related to the target function and converting the functional design requirement into a functional module design requirement further includes:
[0017] Based on the first block definition model, the “lifeline” model element in the first sequence model is decomposed into M “lifeline” model elements of the functional modules;
[0018] Set the "system boundary" model element, "lifeline" model element, "interaction operator" model element, event class "message" model element and operation class "message" model element in the second sequence diagram to establish the second sequence model of the functional module.
[0019] Optionally, the identifying physical components related to the target function and converting the functional module design requirements into physical component design requirements includes:
[0020] Identifying N physical components related to the target function according to the target function; wherein N is an integer greater than or equal to 1;
[0021] The "block" model element, the "directional combination" model element and the "association" model element in the second block definition diagram are set based on the N physical components to establish a second block definition model of the functional module; wherein the "block" model element is the target function and N physical components, the physical components include a sensing component, a control component and an execution component, the "directional combination" model element is the composition relationship between the target function and the control component, and the "association" model element is the electrical connection relationship between the control component and the sensing component, and between the control component and the execution component.
[0022] Optionally, after converting the functional module design requirements into physical component design requirements, the method further includes:
[0023] Establish traceability relationships through the traceability matrix.
[0024] Optionally, establishing a traceability relationship through a traceability matrix includes:
[0025] The traceability relationships between the functional design requirements and the input requirements, the functional module design requirements and the functional design requirements, and the physical component design requirements and the functional module design requirements are respectively established through the traceability matrix.
[0026] According to another aspect of the present invention, there is provided a design device for vehicle electrical and electronic system requirements, comprising:
[0027] An import module, wherein the import module is used to import input requirements related to the target function;
[0028] A first identification module, the first identification module is used to identify functional use cases and convert the input requirements into functional design requirements through scenarios under the functional use cases;
[0029] A second identification module, the second identification module is used to identify the functional modules related to the target function and convert the functional design requirements into functional module design requirements;
[0030] A third identification module is used to identify physical components related to the target function and convert the functional module design requirements into physical component design requirements.
[0031] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the design method for vehicle electronic and electrical system requirements described in any embodiment of the present invention when executed.
[0032] The technical solution provided by the embodiment of the present invention is a model-based vehicle electronic and electrical system requirement design method, which defines the software and hardware requirements of electronic and electrical components by model designing input requirements, functional design requirements, functional module design requirements and physical component design requirements. According to the benefits naturally brought by the model, the model is the only source, and the designer can accurately find a certain module to avoid the situation where the paper document has a clerical error that leads to the wrong module. It can improve the standardization of the electronic and electrical system requirement design and the efficiency of requirement definition, thereby shortening the response cycle of the whole vehicle electronic and electrical products to the market. The technical solution provided by the embodiment of the present invention solves the problems that the existing technology has risks such as poor consistency and difficulty in demand tracing, resulting in low efficiency in demand definition and a long response cycle of the whole vehicle electronic and electrical products to the market.
[0033] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0035] Figure 1 A flow chart of a method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention;
[0036] Figure 2 A flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention;
[0037] Figure 3 A flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention;
[0038] Figure 4 A flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention;
[0039] Figure 5 A flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention;
[0040] Figure 6 A schematic diagram of the scope of use of model elements in each step provided in an embodiment of the present invention;
[0041] Figure 7A schematic diagram of a "demand" model element for inputting requirements provided in an embodiment of the present invention;
[0042] Figure 8 A schematic diagram of the use case diagram model elements provided for an embodiment of the present invention;
[0043] Fig. 9 A schematic diagram of a sequence diagram model element for a function analysis phase provided by an embodiment of the present invention;
[0044] Fig.10 A schematic diagram of a block definition diagram model element in the logical architecture analysis phase provided by an embodiment of the present invention;
[0045] Fig.11 A schematic diagram of a sequence diagram model element of a logical architecture analysis phase provided by an embodiment of the present invention;
[0046] Fig.12 A schematic diagram of a block definition diagram model element in the physical architecture analysis phase provided by an embodiment of the present invention;
[0047] Fig.13 A schematic diagram of the structure of a device for designing vehicle electronic and electrical system requirements provided by an embodiment of the present invention;
[0048] Fig.14 A schematic diagram of the structure of an electronic device for a method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0049] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0050] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention 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 interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0051] Figure 1 The flowchart of a vehicle electronic and electrical system requirements design method provided by an embodiment of the present invention is applicable to the design of vehicle electronic and electrical system requirements. The method can be executed by a vehicle electronic and electrical system requirements design device, which can be implemented by SysMl and UML modeling tools, such as PREEVision, Rhapsody, CATIAMagic, Enterprise Architect and other software. Figure 1 , the design method includes:
[0052] S110. Import input requirements related to the target function.
[0053] Among them, the target function can be determined in advance according to the design requirements; related can be understood as having an interactive relationship with the target function after analysis and screening, for example, having an interactive relationship with the target function in terms of usage scenarios, function realization, control, electrical connection, etc.; input requirements include regulatory requirements, product planning requirements, etc.
[0054] Specifically, the original requirements analysis team analyzes the stakeholder requirements, extracts the requirements related to the target function and stores them in the Electrical and Electronic Development Lifecycle Management System (ELM), defines the requirements as input requirements, and then imports the input requirements related to the target function from the ELM; if there is no Electrical and Electronic Development Lifecycle Management System, the input requirements related to the target function are also imported through documents. Stakeholder requirements can be collected through questionnaires, interviews with users, manufacturers, designers, maintenance personnel, and testers.
[0055] S120. Identify functional use cases and convert input requirements into functional design requirements through scenarios under the functional use cases.
[0056] Among them, the use case defines what the stakeholders want the target function in the vehicle's electronic and electrical system to do, and which stakeholders the target function in the vehicle's electronic and electrical system interacts with.
[0057] Specifically, determine the stakeholder roles of the target function based on the input requirements, analyze the needs and expectations of the stakeholder roles, consider the usage process and usage scenarios of the stakeholder roles under the target function, and thus identify the functional use cases. The scenarios under the functional use cases convert the input requirements into functional design requirements.
[0058] S130, identifying functional modules related to the target function and converting functional design requirements into functional module design requirements.
[0059] Specifically, the identification of functional modules requires designers to complete it according to the purpose of the functional modules and in combination with the functional design requirements, determine the interaction between the target function and the functional module based on the functional design requirements, and convert the functional design requirements into functional module design requirements.
[0060] S140, identifying physical components related to the target function and converting functional module design requirements into physical component design requirements.
[0061] Specifically, the identification of physical components requires designers to complete it based on the purpose of the physical components and in combination with the functional module design requirements, determine the interaction between the target function and the physical components based on the functional module design requirements, and convert the functional module design requirements into physical component design requirements.
[0062] The technical solution provided by the embodiment of the present invention is a model-based vehicle electronic and electrical system requirement design method, which defines the software and hardware requirements of electronic and electrical components by model designing input requirements, functional design requirements, functional module design requirements and physical component design requirements. According to the benefits naturally brought by the model, the model is the only source, and the designer can accurately find a certain module to avoid the situation where the paper document has a clerical error that leads to the wrong module. It can improve the standardization of the electronic and electrical system requirement design and the efficiency of requirement definition, thereby shortening the response cycle of the whole vehicle electronic and electrical products to the market. The technical solution provided by the embodiment of the present invention solves the problems that the existing technology has risks such as poor consistency and difficulty in demand tracing, resulting in low efficiency in demand definition and a long response cycle of the whole vehicle electronic and electrical products to the market.
[0063] Figure 2 This is a flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention. The embodiment of the present invention further refines the above embodiment on the basis of the above embodiment. Figure 2 , the design method includes:
[0064] S210. Import input requirements related to the target function.
[0065] S220. Set the "participant" model element, "use case" model element, "bounding box" model element and "association" model element in the use case diagram according to the input requirements to establish a use case model of the target function.
[0066] Among them, the "use case" model element is the relevant use of the target function, the "actor" model element is the actor of the target function use case, the "bounding box" model element is the target function of the vehicle, and the "association" model element is the relationship between the actor and the use case.
[0067] Specifically, the functional use cases are identified and modeled through the use case diagram. The "participant" model element, "use case" model element, "bounding box" model element and "association" model element in the use case diagram are set according to the input requirements to establish a use case model of the target function.
[0068] S230. Set the “system boundary” model element, “lifeline” model element, “interaction operator” model element, event class “message” model element and operation class “message” model element in the first sequence diagram in the scenario under the functional use case to establish the first sequence model of the target function.
[0069] Among them, the "system boundary" model element is the participant of the target function use case, the "lifeline" model element is the target function of the vehicle, the event-type "message" model element is the interaction between the participant and the vehicle, the operation-type "message" model element is the vehicle's action, and the "interaction operator" model element is the mainstream and branch of the scenario.
[0070] Specifically, the scenarios under the functional use cases are modeled through sequence diagrams. In the scenarios under the functional use cases, the "system boundary" model element, "lifeline" model element, "interaction operator" model element, event class "message" model element, and operation class "message" model element in the first sequence diagram are set to establish the first sequence model of the target function. The event class "message" model element and the operation class "message" model element are functional design requirements.
[0071] S240, identifying functional modules related to the target function and converting functional design requirements into functional module design requirements.
[0072] S250, identifying physical components related to the target function and converting functional module design requirements into physical component design requirements.
[0073] Figure 3 This is a flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention. The embodiment of the present invention further refines the above embodiment on the basis of the above embodiment. Figure 3 , the design method includes:
[0074] S310. Import input requirements related to the target function.
[0075] S320, identify functional use cases and convert input requirements into functional design requirements through scenarios under the functional use cases.
[0076] S330 , identifying M functional modules related to the target function based on the target function.
[0077] Wherein, M is an integer greater than or equal to 1.
[0078] S340, setting the "block" model element and the "directional combination" model element in the first block definition diagram according to the M functional modules to establish a first block definition model of the functional modules.
[0079] Among them, the “block” model elements are the target function and M functional modules, and the “directional combination” model elements are the composition relationship between the target function and M functional modules.
[0080] Specifically, the relationship between the target function and the functional module is modeled using a block definition diagram. After determining the relationship between the target function and the functional module, the "lifeline" model elements in the first sequence model are disassembled into "lifeline" model elements of M functional modules to form a sequence diagram of the functional modules.
[0081] S350. Based on the first block definition model, decompose the “lifeline” model element in the first sequence model into “lifeline” model elements of M functional modules.
[0082] S360. Set the “system boundary” model element, “lifeline” model element, “interaction operator” model element, event class “message” model element and operation class “message” model element in the second sequence diagram to establish a second sequence model of the functional module.
[0083] Among them, the event class "message" model element and the operation class "message" model element are the design requirements of the functional module.
[0084] S370, identifying physical components related to the target function and converting functional module design requirements into physical component design requirements.
[0085] Figure 4 This is a flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention. The embodiment of the present invention further refines the above embodiment on the basis of the above embodiment. Figure 4 , the design method includes:
[0086] S410. Import input requirements related to the target function.
[0087] S420, identify functional use cases and convert input requirements into functional design requirements through scenarios under the functional use cases.
[0088] S430, identifying functional modules related to the target function and converting the functional design requirements into functional module design requirements.
[0089] S440. Identify N physical components related to the target function according to the target function.
[0090] Wherein, N is an integer greater than or equal to 1.
[0091] S450. Set the "block" model element, the "directional combination" model element and the "association" model element in the second block definition diagram based on N physical components to establish a second block definition model of the functional module.
[0092] Among them, the "block" model elements are the target function and N physical components, the physical components include sensing components, control components and execution components; the "directional combination" model elements are the composition relationship between the target function and the control components; the "association" model elements are the electrical connection relationships between the control components and the sensing components, and between the control components and the execution components.
[0093] Specifically, the relationship between the target function and the physical component is modeled with a block definition diagram, and the "association" model element is the physical component design requirement. The functional module design requirements are converted into physical component design requirements, and the mapping relationship between the functional module and the physical component is designed through a "mapping table", indicating that the functional module is implemented by a specific physical component, and the "message" model element of the operation class of the functional module is passed to the physical component. At the same time, the "flow attribute" model element is added to the physical component as a communication relationship, thereby completing the conversion of the functional module design requirements into the physical component design requirements.
[0094] Figure 5 This is a flow chart of another method for designing vehicle electrical and electronic system requirements provided by an embodiment of the present invention. The embodiment of the present invention further refines the above embodiment on the basis of the above embodiment. Figure 5 , the design method includes:
[0095] S510. Import input requirements related to the target function.
[0096] S520, identifying functional use cases and converting input requirements into functional design requirements through scenarios under the functional use cases.
[0097] S530, identifying functional modules related to the target function and converting the functional design requirements into functional module design requirements.
[0098] S540, identifying physical components related to the target function and converting the functional module design requirements into physical component design requirements.
[0099] S550. Establish a traceability relationship through a traceability matrix.
[0100] Optionally, the traceability relationship established through the traceability matrix includes:
[0101] Through the traceability matrix, the traceability relationship between functional design requirements and input requirements, functional module design requirements and functional design requirements, and physical component design requirements and functional module design requirements are established respectively.
[0102] The following is a specific example of a design method for vehicle electrical and electronic system requirements provided by the present application. The embodiment of the present invention is illustrated by taking a DC charging function as an example.
[0103] The DC charging function is designed to capture the requirements of the physical components in the vehicle associated with this function, including the following steps:
[0104] Demand analysis phase: Import input requirements related to DC charging functions from the vehicle demand management library.
[0105] Functional analysis phase: Identify functional use cases and convert input requirements into functional design requirements through scenarios under DC charging functional use cases, and establish traceability relationships.
[0106] Logical architecture analysis phase: Identify the functional modules related to the DC charging function, convert the functional design requirements into functional module design requirements, and establish a traceability relationship.
[0107] Physical architecture analysis phase: Identify the physical components related to the DC charging function, convert the functional module design requirements into physical component design requirements, and establish a traceability relationship.
[0108] Figure 6 A schematic diagram of the scope of use of model elements in each step provided in an embodiment of the present invention.
[0109] Requirements analysis phase:
[0110] The design of converting stakeholder requirements into DC charging function input requirements needs to be completed by the original requirements analysis team; DC charging function input requirements are imported from ELM, including regulatory requirements, product planning requirements, etc. All input requirements are modeled with "requirement" model elements, such as Figure 7 As shown, Figure 7 A schematic diagram of the "Requirement" model element for inputting requirements provided in an embodiment of the present invention.
[0111] Functional analysis phase:
[0112] Identify the use cases of DC charging function and design the model through the use case diagram. In the use case diagram, the "participant" model elements are the driver and the charger. The "use case" model elements include starting DC charging when the vehicle high voltage is powered on, starting DC charging when the vehicle high voltage is not powered on, stopping DC charging by the charger, and stopping DC charging by the vehicle. The "bounding box" model element is the DC charging function, and the "association" model element is the relationship between the driver and the charger and the four use cases, such as Figure 8 As shown, Figure 8A schematic diagram of the model elements of the use case diagram provided for an embodiment of the present invention. The use case of starting DC charging when the vehicle is powered on at high voltage includes scenarios such as the driver starting charging through a mobile phone or the driver starting charging by swiping a card. The model is designed using a sequence diagram. The "system boundary" model element in the sequence diagram is the use case participants, the driver and the charger. The "lifeline" model element is the DC charging function. The event-type "message" model element is the interaction between the participant and the vehicle, such as the connection of the charging gun to the charging socket, the indication that the charging gun is connected, etc. The operation-type "message" model element is the vehicle's action, such as the vehicle detecting that the charging connection is normal and the charging connection indicator is on. The "interaction operator" model element is the different branches of the scenario, such as starting with a mobile phone or swiping a card, such as Fig. 9 As shown, Fig. 9 A schematic diagram of the model elements of the sequence diagram of the functional analysis phase provided by an embodiment of the present invention. All the "message" model elements in the figure are the functional design requirements of the DC charging function. The traceability relationship between the functional design requirements and the input requirements is designed through the "traceability matrix", and a traceability matrix table is formed to display the traceability relationship between the functional design requirements and the input requirements.
[0113] Logical architecture analysis phase:
[0114] The relevant functional modules of the DC charging function include DC charging management, high-voltage power supply management, vehicle speed calculation, power battery monitoring, high-voltage insulation monitoring, charging relay control, main and negative relay control, accessory relay control, DCDC control, and HMI display. The relationship between the DC charging function and the 10 functional modules is determined by the block definition diagram. The "block" model element in the block definition diagram is the DC charging function and the 10 functional modules, and the "directional combination" model element indicates that the DC charging function is composed of 10 functional modules, such as Fig.10 As shown, Fig.10 Schematic diagram of block definition diagram model elements in the logical architecture analysis phase provided by the embodiment of the present invention. After determining the relationship between functions and functional modules, it is necessary to Fig. 9 The DC charging function "lifeline" in the system is broken down into multiple functional module "lifelines". It is necessary to determine which functional modules are related to the system. Fig. 9 The relevant functional modules in the scenario of starting DC charging when the vehicle is powered on at high voltage include: DC charging management, high voltage power supply management, vehicle speed calculation, charging relay control, main and negative relay control, accessory relay control, DCDC control, and HMI display. Fig. 9The DC charging function "lifeline" in the sequence diagram shown is decomposed into 8 functional module "lifelines". The "system boundary" model elements in the sequence diagram are the use case participants, the driver and the charger. The "lifeline" model elements are the functional modules DC charging management, high-voltage power management, vehicle speed calculation, charging relay control, main and negative relay control, accessory relay control, DCDC control, and HMI display. The event-type "message" model elements are the interactions between participants and functional modules, and between functional modules, such as the connection of the charging gun to the charging socket, the handshake of the charger to the vehicle, etc. The operation-type "message" model elements are the actions of the functional modules, such as detecting whether the CC2 voltage is 12V, whether the handshake message of the charger is received, etc. The "interaction operator" model elements are different branches of the scene, such as Fig.11 As shown, Fig.11 A schematic diagram of the sequence diagram model elements of the logical architecture analysis phase provided for an embodiment of the present invention, wherein all "message" models in the figure are the functional module design requirements of each functional module; the traceability relationship between the functional module design requirements and the functional design requirements is designed through the "traceability matrix", forming a traceability matrix table for displaying the traceability relationship between the functional module design requirements and the functional design requirements.
[0115] Physical architecture analysis phase:
[0116] The physical components related to the DC charging function include the vehicle controller, battery management system, all-in-one controller, instrument, ignition switch ON, charging socket A+, charging socket CC2, charging socket temperature sensor, charging positive relay, charging negative relay, main negative relay, and accessory relay; the relationship between the DC charging function and the physical components is modeled using a block definition diagram. The "block" model element in the block definition diagram is the DC charging function and 12 physical components, the "directional combination" model element is the composition relationship between the function and the control component, such as the DC charging function is realized by the vehicle controller, battery management system, all-in-one controller, and instrument combination, and the "association" model element is the electrical connection relationship between the control component and the sensor component, and the control component and the execution component, such as the battery management system physically connects the ignition switch ON, charging socket A+, charging socket CC2, charging socket temperature sensor, charging positive relay, charging negative relay and main negative relay, and the all-in-one controller is physically connected to the accessory relay, such as Fig.12 As shown, Fig.12 A schematic diagram of the model elements of the block definition diagram in the physical architecture analysis phase provided by an embodiment of the present invention, wherein the “association” model element is the physical component design requirement.
[0117] The functional module design requirements are converted into physical component design requirements. The mapping relationship between the functional module and the physical component is designed through the "mapping table", indicating that the functional module is implemented by a specific physical component, such as the battery management system implements 5 functional modules of DC charging management, charging relay control, high-voltage insulation monitoring, main and negative relay control and power battery detection, the all-in-one controller implements 2 functional modules of accessory relay control and DCDC control, the instrument implements 1 functional module of HMI display function module, and the vehicle controller implements 2 functional modules of vehicle speed calculation and high-voltage power supply management. Among them, the "message" model element of the operation class of the functional module is passed to the physical component and becomes the physical component design requirement of the physical component; at the same time, the "flow attribute" model element is added to the physical component as a communication relationship, and the mapping relationship between the communication relationship and the design requirements of the "message" model element of the functional module event class is designed through the "mapping table", and the traceability relationship between the physical component design requirements and the functional module design requirements is designed through the "traceability matrix", forming a traceability matrix table to show the traceability relationship between the physical component design requirements and the functional module design requirements.
[0118] The above embodiment is only a specific implementation of a certain function in the electronic and electrical system. When multiple functions need to be carried out in parallel, each designer can also apply the method of the present invention to form a systematic and standardized demand design model.
[0119] The technical solution provided by the embodiment of the present invention, by formulating a systematic and standardized method for using model elements, models are designed for input requirements, functional design requirements, functional module design requirements and physical component design requirements, defines the software and hardware requirements of electronic and electrical components, and determines traceability relationships to facilitate change search and positioning, thereby further effectively improving the standardization of electronic and electrical system requirement design and the efficiency of requirement definition, thereby shortening the response cycle of vehicle electronic and electrical products to the market.
[0120] Fig.13 A schematic diagram of a design device for vehicle electronic and electrical system requirements provided by an embodiment of the present invention. Fig.13 As shown, the design device includes: an import module 1301, a first recognition module 1302, a second recognition module 1303 and a third recognition module 1304.
[0121] The import module 1301 is used to import input requirements related to the target function.
[0122] The first identification module 1302 is used to identify functional use cases and convert input requirements into functional design requirements through scenarios under the functional use cases.
[0123] The second identification module 1303 is used to identify the functional modules related to the target function and convert the functional design requirements into functional module design requirements.
[0124] The third identification module 1304 is used to identify physical components related to the target function and convert the functional module design requirements into physical component design requirements.
[0125] The device for designing vehicle electrical and electronic system requirements provided in the embodiment of the present invention can execute the method for designing vehicle electrical and electronic system requirements provided in any embodiment of the present invention, and has functional modules and beneficial effects corresponding to the execution method.
[0126] Fig.14 A schematic diagram of the structure of an electronic device for a design method for vehicle electrical and electronic system requirements provided by an embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.
[0127] like Fig.14 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0128] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.
[0129] The processor 11 may be a variety of general and / or dedicated processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the design method for the requirements of the vehicle's electronic and electrical system.
[0130] In some embodiments, the design method for vehicle electrical and electronic system requirements may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the design method for vehicle electrical and electronic system requirements described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the design method for vehicle electrical and electronic system requirements in any other appropriate manner (e.g., by means of firmware).
[0131] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0132] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.
[0133] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0134] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).
[0135] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.
[0136] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.
[0137] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.
[0138] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A design method for vehicle electrical and electronic system requirements, characterized in that: include: Import input requirements related to target functions; Identify functional use cases and transform the input requirements into functional design requirements through scenarios under the functional use cases; Identify functional modules related to target functions and convert the functional design requirements into functional module design requirements; Identify physical components related to the target function and convert the functional module design requirements into physical component design requirements.
2. The design method according to claim 1, characterized in that: The identifying of functional use cases and converting the input requirements into functional design requirements through scenarios under the functional use cases includes: The "participant" model element, "use case" model element, "bounding box" model element and "association" model element in the use case diagram are set according to the input requirements to establish a use case model of the target function; wherein the "use case" model element is the relevant use of the target function, the "participant" model element is the participant of the use case of the target function, the "bounding box" model element is the target function of the vehicle, and the "association" model element is the relationship between the participant and the use case.
3. The design method according to claim 2, characterized in that: The identifying the functional use case and converting the input requirements into functional design requirements through the scenarios under the functional use case also includes: The "system boundary" model element, "lifeline" model element, "interaction operator" model element, event class "message" model element and operation class "message" model element in the first sequence diagram are set in the scenario under the functional use case to establish the first sequence model of the target function; wherein the "system boundary" model element is the participant of the target function use case, the "lifeline" model element is the target function of the vehicle, the event class "message" model element is the interaction between the participant and the vehicle, the operation class "message" model element is the action of the vehicle, and the "interaction operator" model element is the mainstream and branch of the scenario.
4. The design method according to claim 1, characterized in that: The identifying of the functional modules related to the target function and converting the functional design requirements into functional module design requirements comprises: Based on the target function, M functional modules related to the target function are identified; wherein M is an integer greater than or equal to 1; The "block" model element and the "directional combination" model element in the first block definition diagram are set according to the M functional modules to establish a first block definition model of the functional module; wherein the "block" model element is the target function and the M functional modules, and the "directional combination" model element is the composition relationship between the target function and the M functional modules.
5. The design method according to claim 4, characterized in that: The identifying of the functional modules related to the target function and converting the functional design requirements into functional module design requirements also includes: Based on the first block definition model, the “lifeline” model element in the first sequence model is disassembled into M “lifeline” model elements of the functional modules; Set the "system boundary" model element, "lifeline" model element, "interaction operator" model element, event class "message" model element and operation class "message" model element in the second sequence diagram to establish the second sequence model of the functional module.
6. The design method according to claim 1, characterized in that: The identifying of physical components related to the target function and converting the functional module design requirements into physical component design requirements includes: Identifying N physical components related to the target function according to the target function; wherein N is an integer greater than or equal to 1; The "block" model element, the "directional combination" model element and the "association" model element in the second block definition diagram are set based on the N physical components to establish a second block definition model of the functional module; wherein the "block" model element is the target function and N physical components, the physical components include a sensing component, a control component and an execution component, the "directional combination" model element is the composition relationship between the target function and the control component, and the "association" model element is the electrical connection relationship between the control component and the sensing component, and between the control component and the execution component.
7. The design method according to any one of claims 1 to 6, characterized in that: After converting the functional module design requirements into physical component design requirements, the method further includes: Establish traceability relationships through the traceability matrix.
8. The design method according to claim 7, characterized in that: The establishment of a traceability relationship through a traceability matrix includes: The traceability relationships between the functional design requirements and the input requirements, the functional module design requirements and the functional design requirements, and the physical component design requirements and the functional module design requirements are respectively established through the traceability matrix.
9. A design device for vehicle electronic and electrical system requirements, characterized in that: include: An import module, wherein the import module is used to import input requirements related to the target function; A first identification module, the first identification module is used to identify functional use cases and convert the input requirements into functional design requirements through scenarios under the functional use cases; A second identification module, the second identification module is used to identify the functional modules related to the target function and convert the functional design requirements into functional module design requirements; A third identification module is used to identify physical components related to the target function and convert the functional module design requirements into physical component design requirements.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the design method for vehicle electronic and electrical system requirements according to any one of claims 1 to 8 when the instructions are executed.