A Modeling System and Method Based on Multiview Unified Modeling Language

Abstract

The present invention relates to a modeling system and method based on a multi-view unified modeling language, including an attribute meta-model construction unit, a role meta-model construction unit, a relationship meta-model construction unit, a point meta-model construction unit, an object meta-model construction unit, and a graph meta-model construction unit. First, the meta-model design of a specific domain modeling language for intelligent electric vehicles is carried out, and the top-level concept graph, state transition description graph, vehicle feature graph, fault tree analysis graph, etc. of the system are constructed by using the above meta-models. Through the processes of mission analysis, operation concept analysis of intelligent electric vehicles, feature and function analysis, logical analysis, and physical architecture analysis, the architecture modeling of intelligent electric vehicles is carried out. The present invention provides a good modeling language construction environment and modeling environment, and provides a meta-model construction environment, which can not only meet the standardized modeling language, but also design the modeling language according to the business requirements of specific equipment fields.

Description

Technical Field

[0001] The present invention relates to the technical field of complex system modeling, and in particular, to a modeling system and method based on a multi-view unified modeling language. Background Art

[0002] With the increase in the complexity of equipment systems, model-based systems engineering (MBSE) can effectively support the requirements, design, analysis, verification, and validation activities of the entire life cycle of complex systems, and improve the equipment design efficiency. However, the modeling of complex system architectures for equipment often involves multiple stages and multiple fields. The limited types of diagrams in the modeling language specifications result in a lack of description of the entire life cycle of complex systems; the inconsistency of the semantics of different modeling languages leads to ambiguity and quality degradation of models; the inconsistent underlying data of models constructed by heterogeneous modeling tools makes model integration and interaction difficult, thus reducing the overall digital R & D efficiency of equipment.

[0003] Model-based method: Its basic idea is to use mathematical abstractions with some known characteristics to construct models for the state characteristics, behavior characteristics, etc. of the target system. Such as Z language, B language, Petri net, graph theory, etc. are all model-based methods. Each model-based method will propose a set of its own specifications and then use mathematical methods to explain the specifications.

[0004] The Z language is a notation for writing specifications, based on typed set theory and first-order logic. In addition, it contains many constructs for constructing specifications, especially schemas. The use of schemas provides a specification calculus through which the specifications of large systems can be built from smaller parts. As a low-level formal notation, the schema structure of Z can be directly linked to the concepts of classes and class structures, providing a clear link between object-oriented structures and the interpretation of formal expressions. France et al. formally expressed UML class diagrams in the Z language, defined the concepts of classes, class instances, and class associations, and provided a formal form of set and generalization structures. Through the formalization of class diagrams, a deeper understanding of the model structure can be obtained, and strict reasoning can be carried out on the attributes of the model. However, the generation of Z specifications derived from semantic models is very cumbersome.

[0005] The B language is a language based on set theory, generalized substitution language, and first-order logic. It is a formal software development method that covers the software process from specification to implementation. It consists of a set of variables, invariance properties related to these variables, and operations. The state of the system, that is, the set of variable values, can only be modified through operations. Lano et al. defined a transformation from UML class diagrams to the B language to verify the consistency of UML models and verify the expected properties of these models. Since the B language is targeted at the attributes of software development, it lacks generality for complex system modeling.

[0006] Petri nets are used for behavioral modeling at all stages of the system life cycle, from architecture to detailed design. For example, Levis et al. used Petri nets to model the architecture of discrete event distributed intelligent systems. Wang et al. proposed a method for modeling manufacturing control systems using Petri nets. SysML activity diagrams provide a relatively easy-to-understand description of system behavior, but do not directly perform formal correctness analysis. If there is no formal verification method, the system may not be verified until the implementation stage. Petri nets provide formal syntax and semantics for behavioral modeling and support formal analysis of system models. Edward et al. defined formal mathematical symbols for a set of modeling elements in SysML activity diagrams, gave mapping rules between Petir nets and activity diagrams, and formalized a set of behavioral models in activity diagrams into equivalent Petir net models, applying the analysis capabilities of Petri nets to verify system behavior. The formalization of Petri nets is mainly used for the analysis of activity and behavior diagrams.

[0007] According to the current research status at home and abroad, scholars and researchers have conducted extensive and in-depth research on the abstract models of model-based equipment complex system design processes, model formal representation, modeling languages ​​and tools, and have achieved many valuable research results. However, there are still some shortcomings or deficiencies, which are specifically manifested in the following aspects.

[0008] (1) The design of complex equipment systems includes model-based task analysis, requirement decomposition and traceability, and system design and evaluation life cycle processes. The current abstract models are difficult to achieve both completeness and self-consistency, which makes it difficult to describe the life cycle of complex equipment systems consistently. There is a lack of a unified, complete, and self-consistent abstract model that can extract common modeling elements to achieve a hierarchical and progressive unified model expression process.

[0009] (2) In the process of modeling the architecture of complex equipment systems, the unified description of the multi-stage and multi-domain modeling elements of the system life cycle and the establishment of their interrelationships must be strictly logical and rigorous in order to avoid ambiguity in human cognition and ensure the consistency of computer execution. Graph theory can accurately define the formalization of system functions using mathematical theories, but there is still a lack of a formal representation method that can accurately, clearly, and consistently solve the problem of the complex life cycle of equipment for a unified abstract model. The design of the architecture of smart electric vehicles involves the influence of road conditions, driving, environment, and communication, and is a complex system design process. Especially in intelligent transportation systems, with the increase in the number of vehicles, the expansion of the road network, and the increase in terminal devices, the network system is complex, the system interactions are numerous, and the system uncertainty increases, facing the problem of increasingly complex forward architecture design of vehicles.

[0010] (3) Currently, there are multiple modeling languages for MBSE. Each modeling language has applicable lifecycle stages or applicable domains. However, in the process of designing complex equipment systems, the modeling languages of view types lack a unified underlying semantic specification. It is difficult for a single modeling language to meet the design requirements of the system lifecycle. The joint application of multiple modeling languages faces problems such as semantic inconsistency and interface issues between tools. Therefore, there is a lack of a multi-view unified modeling language and environment with the ability to integrate the specifications of various modeling languages in the lifecycle of complex equipment systems to improve design efficiency and model accuracy. Summary of the Invention

[0011] In view of the above problems, the present invention provides a modeling system and method based on a multi-view unified modeling language, providing a meta-model construction environment, which can not only meet the standardized modeling language but also design a modeling language according to the business requirements of specific equipment fields. It improves the adaptability and model integration ability of the modeling platform, is more suitable for the actual modeling needs of enterprises, and can effectively provide system multi-domain and multi-stage modeling support for equipment system designers.

[0012] The present invention provides a modeling system based on a multi-view unified modeling language, characterized in that it includes

[0013] An attribute meta-model construction unit for constructing an attribute meta-model, which is used to define attribute types, identified by the keyword Property. The attribute meta-model becomes an attribute of other meta-model elements after being inherited; the attribute meta-model includes name, automotive integrity level, characteristic parameters, cardinality, cost, components, and actuator roles.

[0014] A role meta-model construction unit for constructing a role meta-model, which is used to define how object types connect relationship types, identified by the keyword Role. The relationship indirectly associates objects on the role; the role meta-model is configured in the relationship meta-model to implement the performance of the relationship.

[0015] A relationship meta-model construction unit for constructing a relationship meta-model, which is used to define the connection relationship between object meta-models, identified by the keyword Relationship.

[0016] The point element model construction unit is used to construct a point element model, which is used to provide additional semantics or constraints on how objects are connected by relationships and is instantiated by the unique identifier pointSystemName. The point element model includes input and output ports of a flow, software I / O input and output ports, and power hardware pin input and output ports. The input and output ports of the flow define the input and output interface attributes and location attributes of the control flow. The software I / O input and output ports define the ports for information exchange between the vehicle host and the controlled object. The power hardware pin input and output ports define the port information of the pins related to the vehicle power system hardware.

[0017] The object element model construction unit is used to construct an object element model, which is used to define a group or a class of elements with the same characteristics and is instantiated by the unique identifier objectSystemName.

[0018] The graphic element model construction unit is used to construct a graphic element model, which includes the organization of the object element model and the relationship element model, the definition of bindings, and the definition of decomposition and sectional view modes, and is identified by the keyword Partial.

[0019] Furthermore, the attribute element model has the following characteristics: dependence, where the attribute depends on other elements in the element model and cannot be instantiated alone but can be inherited in other elements; diversity, where the same attribute element model can be inherited by different element model elements to express different attribute meanings; uniqueness, when the keyword unique is included in the element model attribute, the value of the attribute in the instantiated model containing the element model is unique; orderliness, when the number of element model attributes of the same element model or model attributes of the model is greater than 1, requirements can be made on the order of the attributes; initial value, when the keyword initial is included in the element model attribute, an initial value can be assigned to the element model attribute, and the initial value can be an integer type, a real number type, or a string.

[0020] Furthermore, the role element model is instantiated by the unique identifier roleSystemName. The direction of the RType role, and the relationship defines the flow direction of data or the transfer direction of the relationship by declaring the types and directions of the roles at both ends. The directions include the start-end Import and the end-end Export. The role containing Import is the entry of data, and the role containing Export is the exit of data.

[0021] Further, the connection relationship includes satisfaction, feature combination, derivation, and association. The satisfaction relationship is an assertion indicating that an instance of the client module meets the requirements of the provider side; the feature combination relationship defines the combination relationship of vehicle features; the derivation relationship indicates the relationship of a new module obtained based on the original defined module; the association relationship represents a connection existing between instances of vehicle system modules.

[0022] Further, the point meta-model has the following characteristics: dependence. The point meta-model can be defined independently, but the point model must exist depending on the object model. When the object model is deleted, the point model on that object model is also deleted; diversity. Multiple point models can be added to the object model, and the direction of the point model is not restricted; multiplicity. Each point model on the object model can be bound to multiple role models, or in other words, each object model can be connected to multiple relationship models through the point model.

[0023] Further, the object meta-model includes vehicle features, quality requirements, power ports, interface modules, and domain modules. The vehicle feature object is used to instantiate vehicle features; the quality requirement object is used to instantiate vehicle quality-related requirements; the power port object is used to instantiate a specific power port, which can include multiple attribute information; the interface module object includes the attributes of the interface; the domain module object is the classification of the vehicle system from multiple perspectives, including the control domain and the body domain.

[0024] Further, the graphic meta-model determines the basic composition of the graph by declaring the object meta-model class and the relationship meta-model class. The keyword Constraint() represents a constraint, allowing the definition of additional conditions for meta-model elements, and these conditions must be met during or after modeling. It includes a binding constraint: bindconnector() establishes the constraint relationship between objects and relationships, and the specifications for decomposition and sectioning: decompose represents decomposition, supporting the refinement of object, point, and relationship elements, and expanding an element into a graph for detailed description.

[0025] The present invention also provides a modeling method based on the multi-view unified modeling language, which is characterized by including the following steps:

[0026] Construct an attribute meta-model, which is used to define the attribute type, identified by the keyword Property. The attribute meta-model becomes the attribute of other meta-model elements after being inherited. The attribute meta-model includes name, automotive integrity level, characteristic parameters, cardinality, cost, components, and actuator roles.

[0027] Construct a role meta-model, which is used to define how object types connect to relationship types, identified by the keyword Role. Relationships will indirectly associate objects on the role. The role meta-model is configured within the relationship meta-model to achieve the performance of the relationship;

[0028] Construct a relationship meta-model, which is used to define the connection relationships between object meta-models, identified by the keyword Relationship;

[0029] Construct a point meta-model, which is used to provide additional semantics or constraints for how objects are connected through relationships, instantiated by the unique identifier pointSystemName. The point meta-model includes input and output ports of the flow, software I / O input and output ports, and power hardware pin input and output ports. The input and output ports of the flow define the input and output interface attributes and location attributes of the control flow. The software I / O input and output ports define the ports for information exchange between the vehicle host and the controlled object. The power hardware pin input and output ports define the port information of the pins related to the vehicle power system hardware;

[0030] Construct an object meta-model, which is used to define a group or a class of elements with the same characteristics, instantiated by the unique identifier objectSystemName;

[0031] Construct a graph meta-model, which includes the organization of the object meta-model and the relationship meta-model, the definition of bindings, and the definition of decomposition and sectional view modes, identified by the keyword Partial.

[0032] Furthermore, a modeling method based on the multi-view unified modeling language further includes the following steps:

[0033] Mission analysis: Complete the mission task analysis of the intelligent transportation system scenario through the system top-level concept diagram to obtain potential design solutions;

[0034] Operation analysis: For the intelligent electric vehicle in the intelligent transportation system, use the state transition diagram to conduct an operation concept analysis of the intelligent electric vehicle as the target system. By analyzing the life cycle of the intelligent electric vehicle system, determine the starting point of the system analysis and define the candidate operation concept solutions for the mission;

[0035] Feature and function analysis: Conduct intelligent electric vehicle feature modeling through the vehicle feature diagram to achieve function analysis of speed control and intelligence in the driving scenario of the intelligent electric vehicle;

[0036] Logic analysis: Describe the operation behavior changes of the braking system through the logical architecture, and analyze all the logical architectures and the functional flows and interactions between them during the braking process through the sequence diagram;

[0037] Physical architecture analysis determines the physical components corresponding to the objects in the logical model and their quantities, determines the connection relationships between the physical components and the attributes of the physical components, and finally forms the physical architecture.

[0038] Furthermore, before the mission analysis step, there is also a meta-model design step for the specific domain modeling language of intelligent electric vehicles. The system top-level concept diagram, state transition description diagram, use case diagram, sequence diagram, package diagram, sequence diagram, internal module diagram, module definition diagram, flowchart, vehicle feature diagram, vehicle function type description diagram, fault tree analysis and verification diagram are constructed using the attribute meta-model, role meta-model, relationship meta-model, point meta-model, object meta-model, and graph meta-model;

[0039] The system top-level concept diagram describes the mission tasks and their classifications, or scenarios, and is used to describe the interaction between the subject architecture and its environment, as well as the interaction between the architecture and external systems;

[0040] The state transition diagram describes the correspondence of activities to the time sequence, including the initial state, state, set nodes, branch node objects and transitions, and self-transition relationships, and is used to express the state interaction relationship between the target object and the outside;

[0041] The use case diagram describes a specific series of actions, including variant series actions and error series actions, which can be executed by the system, subsystem or class through interaction with external objects to provide value services;

[0042] The package diagram describes the organization method of the system model. The organization method of the system model is determined by the hierarchical relationship of the packages, and the hierarchical relationship of the packages distributes the elements in the model into logically closely related diagrams;

[0043] The sequence diagram describes the dynamic behavior information of the system, illustrates the behavior and time sequence that occur over time, and the various parts of the module interact with each other through operation calls and asynchronous signals to produce emergent behavior;

[0044] The internal module diagram describes the internal structure of a specified single module, is a static view of the system or a component of the system, and is used to show a specific series of connections between the attributes of a certain module. The internal module diagram includes value attributes, composition attributes, constraint attributes, reference attribute objects and connectors, and binding connector relationships;

[0045] The module definition diagram describes the structure of the system, including modules, flow descriptions, systems, system contexts, value type objects and associations, generalizations, and aggregation relationships;

[0046] The described flow chart depicts business process operations, providing a simple mechanism for creating a business process model while being able to handle the complexity from the business process;

[0047] The described vehicle feature diagram depicts the features of a vehicle at the vehicle level, that is, it represents "what is a vehicle?" through various features, and the features that various variants of the vehicle may or may not have;

[0048] The described vehicle function type diagram depicts the functional analysis architecture of the vehicle;

[0049] The fault tree analysis and verification diagram depicts system failure problems and finds the cause of the fault through calculation to reduce risks.

[0050] The beneficial effects produced by the present invention are as follows: The present invention proposes a modeling system and method based on the multi-view unified modeling language. Based on the multi-view unified modeling language, a modeling system based on the multi-view unified modeling language is designed and developed. This system provides a good modeling language construction environment and modeling environment, provides a meta-model construction environment, which can not only meet the standardized modeling language but also design the modeling language according to the business requirements of specific equipment fields; it improves the adaptability and model integration ability of the modeling platform, is more suitable for the actual modeling needs of enterprises, and can effectively support designers in modeling for multiple stages and multiple fields in the complex system life cycle. The modeling process avoids the difficulties of data heterogeneity and interaction caused by multi-modeling tools, unifies the model semantics and data, thus ensuring the quality of the model. Through the construction of each meta-model, a specific domain modeling language for intelligent electric vehicles is jointly formed. Through the construction of this meta-model library, a modeling environment from mission tasks to physical architecture is provided, ensuring the integration of multi-modeling languages for the life cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below:

[0052] Figure 1 Shows a schematic diagram of the modeling system according to the first embodiment of the present invention.

[0053] Figure 2A Shows a meta-model construction flow chart of the modeling method according to the first embodiment of the present invention.

[0054] Figure 2B Shows a flow chart of the modeling method according to the first embodiment of the present invention.

[0055] Figure 3 Shows a schematic diagram of the mission task in the scenario of the present invention.

[0056] Figure 4 Shows a schematic diagram of the operational concept model in the scenario of the present invention.

[0057] Figure 5 Shows the schematic diagram of stakeholder operation analysis in the scenario of the present invention.

[0058] Figure 6 Shows the schematic diagram of driving operation analysis in the scenario of the present invention.

[0059] Figure 7 Shows the schematic diagram of features related to the safety and security of intelligent electric vehicles.

[0060] Figure 8 Shows the schematic diagram of the functional analysis model of intelligent electric vehicles.

[0061] Figure 9 Shows the braking timing diagram with ABS function.

[0062] Figure 10 Shows the schematic diagram of the physical architecture of the intelligent electric vehicle applied in the present invention.

[0063] Figure 11 Shows the schematic diagram of the fault tree modeling applied in the present invention.

[0064] Figure 12 Shows the set of meta-models of the specific domain modeling language for intelligent electric vehicles in the first embodiment of the present invention.

[0065] Figure 13 Shows the top-level conceptual diagram description of the meta-model system of the specific domain modeling language for intelligent electric vehicles.

[0066] Figure 14 Shows the file resources of the meta-model constructed specifically for the modeling language of intelligent electric vehicles. Detailed implementation manners

[0067] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0068] In the following introduction, the terms "first" and "second" are only used for the purpose of description and cannot be construed as implying their relative importance.

[0069] The following introduction provides multiple embodiments of the present invention. Different embodiments can be replaced or combined. Therefore, the present invention can also be considered to include all possible combinations of the same and / or different embodiments described. Thus, if one embodiment includes features A, B, and C, and another embodiment includes features B and D, then the present invention should also be considered to include embodiments containing one or more of all other possible combinations of A, B, C, and D, even if such embodiments may not be explicitly described in the following content.

[0070] The intelligent transportation system includes intelligent electric vehicles, navigation satellites, signal towers, control centers, etc. By leveraging the advantages of the Internet, Internet of Things, and big data technologies and introducing more high-tech devices, it can fully grasp the driving conditions of vehicles and the surrounding transportation environment. When a vehicle faces a sudden road situation, the intelligent transportation system will detect the dangerous situation in the first instance and respond to the emergency. The intelligent transportation system has a complex system, and there are numerous interactions among its various parts during operation, greatly increasing uncertainty. In the top-level mission task R & D system of the intelligent transportation system, the design targeting intelligent electric vehicles involves multiple systems such as the environmental perception system, autonomous driving system, and signal interaction system, which is a complex process.

[0071] The present invention will start from the scenario of two vehicles in the intelligent transportation system automatically braking when encountering an obstacle as the mission task, and carry out the architecture design for intelligent electric vehicles. The scenario is as follows:

[0072] (1) On a one-way road, two vehicles start and depart one after another. The two vehicles wait to depart. The leading vehicle starts and drives at a constant speed, and then the trailing vehicle starts and drives.

[0073] (2) The two vehicles are driving on a straight road at the same time. The leading vehicle is driving at a normal speed, and the trailing vehicle gradually accelerates during driving to catch up with the leading vehicle. Then the trailing vehicle starts to decelerate until it drives at a constant speed with the leading vehicle.

[0074] (3) The control center detects an obstacle in front of the leading vehicle, and the leading vehicle immediately decelerates and stops. The leading vehicle synchronizes the obstacle signal to the trailing vehicle, and the trailing vehicle decelerates and stops. Subsequently, the two vehicles stop driving.

[0075] In the intelligent transportation system, the following information interactions are included:

[0076] (1) Two-way communication between the intelligent electric vehicle and the signal tower;

[0077] (2) The intelligent electric vehicle requests and receives the GPS signal of the communication satellite;

[0078] (3) The intelligent electric vehicle sends radar waves to the surroundings and receives the radar waves reflected by obstacles; (4) The control center receives the signal tower information and sends control instructions.

[0079] In the modeling method of MBSE, there is no forward design method for the product life cycle starting from the mission, and there is no single modeling language that can meet the architecture design of equipment in this scenario. Therefore, the multi-view unified modeling language studied in the present invention is adopted. For the architecture design problem of intelligent electric vehicles in the transportation system, an architecture modeling method starting from mission tasks is adopted to construct a specific domain modeling language for intelligent electric vehicles to meet the forward design of the intelligent electric vehicle architecture in this scenario.

[0080] Example 1

[0081] Figure 1 The schematic diagram of a modeling system based on the multi-view unified modeling language according to the first embodiment of the present invention is shown.

[0082] As Figure 1 shown, the present invention provides a modeling system based on multi-view unified modeling, which is characterized in that:

[0083] The attribute meta-model construction unit 100 is used to construct an attribute meta-model, and the attribute meta-model is used to define the attribute type, which is identified by the keyword Property. The attribute meta-model becomes the attribute of other meta-model elements after being inherited; the attribute meta-model includes name, vehicle integrity level, characteristic parameters, cardinality, cost, components, and actuator role.

[0084] Through the sorting of the abstract syntax classes and the class composition relationships, the attribute classes have different interpretations at different levels. First, it is the meta-model that defines the attributes, which is identified by the keyword Property in the language. The attribute meta-model becomes the attribute of other meta-model elements after being inherited, that is, the meta-model attribute, and then the extends identifier is added in the language; at the model level, the attribute is instantiated as a model attribute, and the refer identifier is added in the language, and the model attribute can contain specific values. The attribute meta-model mainly includes name, vehicle integrity level, characteristic parameters, cardinality, cost, components, actuator role, etc., which are used to configure other meta-models such as the object meta-model and the relationship meta-model. For example, the name attribute, characteristic parameter attribute, cardinality attribute, etc. are configured for the feature object to form a complete expression of the feature object.

[0085] By formalizing the context relationship of the attributes in the representation, the following properties of the attributes are defined:

[0086] (1) Dependence

[0087] The attribute depends on other elements in the meta-model and cannot be instantiated alone. It can be inherited in other elements and is called the meta-model attribute, such as the graph meta-model attribute, object meta-model attribute, point meta-model attribute, relationship meta-model attribute, and role meta-model attribute.

[0088] (2) Diversity

[0089] The same attribute meta - model can be inherited by different meta - model elements to express different attribute meanings.

[0090] (3) Uniqueness

[0091] When the keyword "unique" is included in the meta - model attribute, the value of this attribute in the instantiated model containing this meta - model is unique.

[0092] (4) Orderliness

[0093] When the number of meta - model attributes of the same meta - model or model attributes of the model is greater than 1, requirements can be made on the order of the attributes.

[0094] (5) Initial value

[0095] When the keyword "initial" is included in the meta - model attribute, an initial value can be assigned to the meta - model attribute, and the initial value can be integer type, real type or string, etc.

[0096] The specific syntax of the attribute meta - model class, graph (or object, relationship, role, point) attribute class, and attribute model class is as shown in Syntax 5.1, Syntax 5.2, and Syntax 5.3, where "unit" is the keyword for unit; the type of the attribute value "value" is determined by the data type of the attribute, such as 100 of type Int and "school name" of type String; "description" is the keyword for the literal description of the meta - model, such as the function and scope of adding this attribute; inheritance in the meta - model uses the keyword "extends", and reference in the model uses the keyword "refer"; propertySystemName, graphPropertySystemName, and modelProper - tySystemName are the corresponding unique identifiers respectively.

[0097] The role meta - model construction unit 102 is used to construct the role meta - model. The role meta - model is used to define how object types are connected to relationship types, and is identified by the keyword "Role". Relationships will indirectly associate objects on the role; the role meta - model is configured within the relationship meta - model to implement the performance of the relationship;

[0098] The role classes are divided into role meta - model classes and role model classes: (1) The role meta - model class defines how object types connect to relationship types, which is identified by the keyword Role. The relationship will indirectly associate objects on the role. The role meta - model class is instantiated by the unique identifier roleSystemName. The direction of the RType role, the relationship defines the data flow direction or the relationship transmission direction by declaring the types and directions of the two - end roles of the relationship. The directions include the start - end Import and the end - Export. The role containing Import is the data entry, and the role containing Export is the data exit.

[0099] (2) The role model class is an instantiation of the role meta - model in the model and is inherited through the keyword refer. The role model class is instantiated by the unique identifier roleModelSystemName. In addition to instantiated attributes, it can also be sectioned. It is sectioned into a new model through the keyword explode, such as being sectioned into model2, and the position order of the sectioned model can be defined in the visulizationList. The shape type in the role model class is the same as that of the meta - model and can be changed, but in principle, it follows the shape defined by the meta - model class.

[0100] The relationship meta - model construction unit 104 is used to construct the relationship meta - model, which is used to define the connection relationship between object meta - models and is identified by the keyword Relationship;

[0101] Furthermore, the connection relationship includes satisfy, feature combination, derivation, and association. The satisfy relationship is an assertion indicating that the instance of the client module meets the requirements of the provider module; the feature combination relationship defines the combination relationship of vehicle features; the derivation relationship indicates the relationship of the new module obtained based on the original defined module; the association relationship represents a connection existing between the instances of vehicle system modules.

[0102] (1) The relationship meta - model class is the connection relationship between object meta - model classes, which is identified by the keyword Relationship and is an important part of the structured model. In the meta - model, the relationship meta - model class is defined to establish a connection relationship between object modules. The relationship meta - model class is instantiated by the unique identifier relationshipSystemName.

[0103] (2) The relational model class defines an instantiated relationship, inheriting the relational meta-model with the unique identifier relationshipSystemName through the keyword "refer". In addition to the instantiated attributes, in the graphic meta-model class, a sectional view is declared, and in the model, the keyword "decompose" is used for decomposition and "explode" for sectional view. The relational model class must and can only contain two role model classes. The shape type in the relational model class is the same as that of the meta-model, which can be changed, but in principle, it follows the shape defined by the meta-model class. Secondly, the relational model class can also define fixed syntax attributes such as line width, font, and folding point coordinates.

[0104] The point meta-model construction unit 106 is used to construct the point meta-model, which is used to provide additional semantics or constraints on how objects are connected through relationships and is instantiated through the unique identifier pointSystemName.

[0105] The point meta-model mainly includes input / output ports of the flow, software I / O input / output ports, power hardware pin input / output ports, etc. The input / output ports of the flow define attributes such as the input / output interface attributes and positions of the control flow. The software I / O input / output ports define the ports for information exchange between the vehicle host and the controlled object. The power hardware pin input / output ports define the port information of the pins related to the vehicle power system hardware.

[0106] Points can provide additional semantics or constraints on how objects are connected through relationships. In addition to its own definition, the point meta-model also needs to be declared in the object meta-model. There are three levels in the abstract syntax of points, namely the point meta-model class, the object point class, and the point model class. The three levels of points need to have the following properties during the instantiation process:

[0107] 1) Dependency relationship

[0108] The point meta-model can be defined independently, but the point model must depend on the existence of the object model. When the object model is deleted, the point model on that object model is also deleted.

[0109] 2) Diversity Multiple point models can be added to an object model, and the direction of the point model is not restricted.

[0110] 3) Multiplicity Each point model on an object model can be bound to multiple role models, or in other words, each object model can be connected to multiple relational models through the point model.

[0111] (1) Formal representation The mapping point meta-model class defines the general attributes of the port, is instantiated through the unique identifier pointSystemName, and has no directionality when defined.

[0112] (2) The object point class is the inheritance of the point meta-model class in the object meta-model through the keyword extends. As the interface for the connection between the object itself and the relationship, the object point has directionality. Three types of directions are defined here: Input represents the input direction and is bound to the terminal role; Output represents the output direction and is bound to the start role; Undirected represents no directionality and can be bound to both the start and terminal.

[0113] (3) The point model class defines an instantiated point, which needs to include the keyword refer and the unique identifier of the inherited object point. In addition to the instantiated attributes, the point model class can also be decomposed or dissected into a new model. The shape type in the point model class is the same as that in the meta-model and can be changed, but in principle, it follows the shape defined by the meta-model class. The point model class can be copied into multiple homologous points, each point having the same attributes but being instantiated as different entities. Secondly, the point model class also defines fixed syntactic attributes such as point position, point font, point color, and the points or objects connected by the point.

[0114] The object meta-model construction unit 108 is used to construct the object meta-model, which is used to define a group or a class of elements with the same characteristics and is instantiated through the unique identifier objectSystemName.

[0115] The object meta-model mainly includes vehicle characteristics, quality requirements, power ports, interface modules, domain modules, etc. The vehicle characteristic object is used to instantiate vehicle characteristics, the quality requirement object is used to instantiate vehicle quality-related requirements, the power port object is used to instantiate a specific power port, which can contain more attribute information, the interface module object contains the attributes of complex interfaces and is therefore independent of the interface port, and the domain module object is the classification of the vehicle system from multiple perspectives, such as the control domain, body domain, etc.

[0116] (1) The object meta-model class is an important part of the structured model. The object meta-model class contains attributes and fixed syntax. This object is like the object in the SysML language requirement diagram: requirement. The object meta-model object is instantiated through the unique identifier objectSystemName. In addition to the definition of its own attributes and fixed syntax, the object meta-model can also define object points, and the content of the object points

[0117] is elaborated in the specific syntax of the point. It should be emphasized here that an object can add points or not, that is, the object's dependence on points. The shape of the object meta-model class is related to its mode. The mode determines the visual explicit or implicit characteristics of the view. The object contains two modes: the container mode that displays attributes: propertymode, and the node mode that does not display attributes: blankpropertymode.

[0118] (2) The object model class inherits from the meta-model class through refer and is instantiated into an entity with objectModelSystemName as the unique identifier. In the specific syntax of the object model class, in addition to instantiated attributes, it also includes points, decomposition, sectional views, etc. The shape type of the specific syntax of the object model is the same as that of the meta-model and can be changed, but in principle, it follows the shape defined by the meta-model.

[0119] The graphic meta-model construction unit 110 is used to construct the graphic meta-model. The graphic meta-model includes the organization of the object meta-model and the relationship meta-model, the definition of bindings, and the definition of decomposition and sectional view modes, which are identified by the keyword Partial. The graphic meta-model determines the basic composition of the graph by declaring the object meta-model class and the relationship meta-model class; the keyword Constraint() represents a constraint, allowing the definition of additional conditions for meta-model elements, and these conditions must be satisfied during or after modeling; it includes a binding constraint: bindconnector() establishes the constraint relationship between objects and relationships, and the specification of decomposition and sectional view: decompose represents decomposition, supporting the refinement of objects, points, and relationship elements, and expanding an element into a graph for detailed description.

[0120] The graphic meta-model mainly includes a module definition diagram, a use case diagram, a flowchart, a vehicle feature diagram, a vehicle function type diagram, etc. Here, the module definition diagram is used to describe any entity in the intelligent electric vehicle system, the use case diagram is used to describe the actors and use cases of vehicle functions and the relationships between them, the flowchart is used to describe the relevant design processes of the vehicle, the vehicle feature diagram is used to describe vehicle features, design functions, general constraints, etc., and the vehicle function type diagram is used to describe the function flow inlet, function flow outlet, power port, server port, and other components related to vehicle functions.

[0121] Figure 2A The flowchart of the meta-model construction of a modeling method based on the multi-view unified modeling language according to the first embodiment of the present invention is shown.

[0122] As Figure 2A shown, the present invention also provides a modeling method based on the multi-view unified modeling language, which is characterized by including the following steps:

[0123] S200, construct an attribute meta-model, which is used to define the attribute type, identified by the keyword Property. The attribute meta-model is inherited and becomes the attribute of other meta-model elements;

[0124] The attribute meta-model includes name, vehicle integrity level, characteristic parameters, cardinality, cost, components, actuator roles, etc.;

[0125] S202, construct a role meta-model, which is used to define how object types connect to relationship types, identified by the keyword Role. Relationships will indirectly associate objects on the role. The role meta-model is configured within the relationship meta-model to implement the performance of the relationship;

[0126] S204, construct a relationship meta-model, which is used to define the connection relationships between object meta-models, identified by the keyword Relationship;

[0127] S206, construct a point meta-model, which is used to provide additional semantics or constraints on how objects are connected by relationships, instantiated by the unique identifier pointSystemName. The point meta-model includes input and output ports of the flow, software I / O input and output ports, and power hardware pin input and output ports. The input and output ports of the flow define the input and output interface attributes and location attributes of the control flow. The software I / O input and output ports define the ports for information exchange between the vehicle host and the controlled object. The power hardware pin input and output ports define the port information of the pins related to the vehicle power system hardware;

[0128] S208, construct an object meta-model, which is used to define a group or a class of elements with the same characteristics, instantiated by the unique identifier objectSystemName;

[0129] S210, construct a diagram meta-model, which includes the organization of the object meta-model and the relationship meta-model, the definition of bindings, and the definition of decomposition and sectional view modes, identified by the keyword Partial.

[0130] Furthermore, the modeling method based on the multi-view unified modeling language further includes the following steps: as Figure 2B shown

[0131] Step S302, mission analysis. Complete the mission task analysis of the intelligent transportation system scenario through the system top-level concept diagram, analyze the interaction relationships among intelligent electric vehicles, radio navigation satellites, signal towers, and control centers, and obtain potential design solutions.

[0132] The mission scenario description of two vehicles automatically braking when encountering an obstacle is as follows:

[0133] On a one-way road, two vehicles start and drive off one after the other. The leading vehicle starts and drives at a constant speed. The trailing vehicle starts and drives. The two vehicles drive on a straight road simultaneously. The leading vehicle drives at a normal speed, while the trailing vehicle gradually accelerates during driving and catches up with the leading vehicle. The trailing vehicle then starts to decelerate until it drives at a constant speed with the leading vehicle. The control center detects an obstacle in front of the leading vehicle, and the leading vehicle immediately decelerates and stops. The leading vehicle synchronizes the obstacle signal to the trailing vehicle, and the trailing vehicle decelerates and stops. Subsequently, both vehicles stop driving.

[0134] Based on the description of the above mission scenario, establish a mission task as shown in Figure 3 which includes six actuators. Among them, Electric Vehicle A and Electric Vehicle B have two relationships with the satellite, namely GPS signal request and GPS signal reception, to complete communication with the satellite. At the same time, there will be signal reception and reflection of radar between the two electric vehicles. The electric vehicle transmits the radar and GPS signals fed back by the electric vehicle to the signal tower, and the signal tower transmits the control instructions for the electric vehicle. The relationship between Electric Vehicle B and the obstacle is that Electric Vehicle B emits a radar signal, which is reflected by the obstacle and then the radar signal is received. The relationship between the signal tower and the control center is that the signal tower transmits these two status information to the signal tower, and the control center feeds back the vehicle control instructions to the signal tower. During the entire mission task process, Electric Vehicle B has information interaction with a total of 4 objects, namely the satellite, Electric Vehicle A, the obstacle, and the signal tower.

[0135] Step S304, Run Analysis. For the intelligent electric vehicle in the intelligent transportation system, use the state transition diagram to conduct a run concept analysis on the intelligent electric vehicle as the target system. By analyzing the life cycle of the intelligent electric vehicle system, determine the starting point of system analysis, and define the candidate run concept solutions for the mission. Then derive the stakeholder requirements from the run behavior: conduct a run analysis on the intelligent electric vehicle stakeholders through the use case diagram, and accurately define the expected behaviors of the designer, tester, and driver in each run stage of the system in the subsystem through the use case diagram.

[0136] Select Electric Vehicle B as the research object and study its state interaction relationship with the outside. As Figure 4 Use the state transition diagram to construct a run concept model to describe how the electric vehicle will respond to the events in the scenario, such as Figure 5 and Figure 6 Use the use case diagram to construct stakeholder run analysis, driving run analysis, etc. to describe the interaction between the stakeholders and the electric vehicle system.

[0137] In the operation concept model, electric vehicle B is selected as the object. The initial state is that electric vehicle B is driving at a constant speed on the lane. Then, electric vehicle B uses radar to scan for obstacles. After receiving the obstacle information reflected by the radar, electric vehicle B requests to obtain GPS positioning information. After receiving the GPS information, the state of electric vehicle B is converted into two states through a branch node. On the one hand, it transmits information, sending radar signals and GPS information to electric vehicle A and receiving the confirmation receipt information from electric vehicle A. On the other hand, it requests a decision, sending information to the control center and receiving the instructions feedback from the control center. Then, electric vehicle B takes braking measures and finally stops before the obstacle.

[0138] Four types of stakeholders can be analyzed in the operation concept model: users, physical environment, IT environment, and suppliers. Each stakeholder is associated with multiple modules, such as the basic driving module, advanced driver assistance module, comfort and leisure module, economy and environmental protection module, reliability, availability, maintainability, and safety module. Each module can be further generalized into multiple sub-modules. For example, the basic driving module is generalized into managing trajectory changes, managing vehicle speed, preventing vehicle movement, perceiving and notifying the environment, etc. Here, users can be further refined into drivers, control center personnel, software testers, hardware testers, accountants, software engineers, hardware engineers, etc., who are responsible for the design, testing, cost, and other aspects of electric vehicles. Each type of user is associated with multiple electric vehicle modules. For example, drivers are associated with driving, positioning, navigation, communication, information analysis, and other modules. Through the analysis of stakeholders, we can clarify the characteristic modules involved in electric vehicles.

[0139] Step S306, feature and function analysis. Intelligent electric vehicle feature modeling is carried out through a vehicle feature map, including power control features, perception features, autonomous driving features, lateral control features, and longitudinal control features. According to the features, corresponding function analysis modeling is carried out, including power-train control function analysis, full-autonomous driving control function analysis, global path generation function analysis, lateral control function analysis, and longitudinal control function analysis, to realize the function analysis of speed control and intelligence in the driving scenario of intelligent electric vehicles.

[0140] Features are the integration of a class of related functions oriented to users. Vehicle features can be extended to the functions of the vehicle, and the functions can fully cover the features. Regarding the safety and security aspects of electric vehicles, in this case, 76 safety and security-related features of intelligent vehicles are described through the refinement of the mission task model, operation concept model, and use case model. Figure 7 Shows a schematic diagram of the safety and security-related features of intelligent electric vehicles. Such as Figure 7As shown in the figure, the features of intelligent electric vehicles are divided into eight groups, namely vertical control features, power control features, perception features, autonomous driving features, longitudinal control features, lateral control features, prediction features, and V2X (vehicle to everything, that is, vehicle's information exchange with the outside world) features. Among them, for example, the object perception feature can be further elaborated through the decomposition diagram of perception at the next level by the decomposition mode, including nine sub-features such as internal and external climate, traffic lights and road signs, vehicle status, road unevenness and shape, surrounding objects, tire traction, road signs, driver status, and remote objects. The lateral control feature can be transformed into a steering angle control feature, and the steering angle control feature is divided into autonomous driving control features and manual driving control features. Among them, the autonomous driving control features can be further decomposed into smaller unit control features, such as automatic parking, lane keeping, lane changing, path planning and tracking, obstacle avoidance, lateral stability control, etc.; the manual driving control features can be decomposed into steer-by-wire, obstacle avoidance, and lateral stability control.

[0141] Each feature is implemented by one or more functions, such as Figure 8 As shown in the figure, there are complex relationships among the functions corresponding to the eight groups of features of intelligent electric vehicles related to safety and security. For example, the automatic vehicle perception function corresponding to the perception feature is associated with the longitudinal control through ports such as motor speed, motor torque limit, steering angle, and number of gears, associated with the autonomous driving control through the autonomous perception port, associated with the vertical control function through ports such as pitch angle, vehicle vertical acceleration, vehicle chassis height, vehicle speed, and roll angle, associated with the lateral control function through ports such as vehicle lateral speed, steering angle, yaw rate, and vehicle speed, associated with the powertrain control function through the battery state port, and associated with the brake torque distribution and electronic stability control function through ports such as sideslip angle, tire slip angle, wheel angular velocity, lateral acceleration, and number of gear teeth. Among them, the brake torque distribution and electronic stability control function can be refined into Figure 8 As shown in the figure, the brake torque distribution and electronic stability control function is related to sub-functions such as regenerative braking control function, right rear wheel angular velocity, left rear wheel angular velocity, right front wheel angular velocity, left front wheel angular velocity, vehicle speed, brake torque, lateral acceleration, and steering angle through the flow relationship (Relationship). Among them, the regenerative braking control sub-function is related to functions such as motor torque limit, vehicle speed, and brake torque request through the flow relationship (Relationship). From feature analysis to function analysis, a total of 356 complete functional architectures from sensors to actuators are constructed. After completing the function modeling, the objects that implement this function will be listed according to the system function, and the implementation process of this function will be described through a sequence diagram to complete the logical architecture design.

[0142] Step S308, Logical analysis. Describe the changes in the operating behavior of the braking system through a logical architecture. Analyze all the logical architectures involved in the braking process, as well as the functional flows and interactions between them, through a sequence diagram to determine the physical viewpoint model at the abstract level, which supports the subsequent physical architecture design. At the same time, define the assembly process of the intelligent electric vehicle system, including the vehicle wiring assembly process, interior assembly process, and body assembly process, through a flowchart.

[0143] Logical analysis is to clarify the logical process of system objects participating in the implementation of a certain function through modeling. For example, for the analysis of features and functions related to electric vehicle safety and assurance, the logical process of electric vehicle braking is obtained through sequence diagram analysis.

[0144] Figure 9 The sequence diagram of the braking system with ABS function is shown. The braking function includes wheel speed control, vehicle speed control, ABS control, etc. The corresponding logical components should be classified into wheel speed sensors, ABS anti-lock braking systems, brake actuators, user interactions, etc. The interactions of each logical component expressed through the sequence diagram are as Figure 9 shown. When the user steps on the brake pedal, a brake pedal signal is transmitted, causing the right rear wheel, right front wheel, left rear wheel, and left front wheel to brake. The corresponding sensors collect the wheel speed signals and transmit them to the ABS anti-lock braking system. When the vehicle slips on the right side, the right wheel speed is abnormal. The ABS anti-lock braking system issues an instruction to the braking torque, and at the same time stops the anti-lock intervention on the left wheels. The braking torque detects the torque of the right front wheel and the right rear wheel and transmits it to the acceleration braking torque combination. After calculation by the braking torque, it is fed back to the ABS anti-lock braking system. The ABS anti-lock braking system takes braking intervention measures on the right front wheel and the right rear wheel through internal operations, and through regenerative braking control, intervenes in the speed and torque from the power source, thus completing a safe braking.

[0145] Step S210, Physical architecture analysis. Determine the physical components corresponding to the objects in the logical model and their quantities, and then determine the connection relationships between the physical components and the attributes of the physical components, finally forming the physical architecture. It may include using a package diagram to decompose the physical structure of driving control, using an internal module diagram to analyze the driving control logic therein, then using a module definition diagram to analyze the physical interfaces of driving control, and finally using a fault tree analysis diagram to conduct fault tree analysis and verification on the fault situations in the driving control process.

[0146] Physical architecture analysis is based on the objects in the logical model. With the support of experience or a database, clarify the corresponding physical components and their quantities, etc., and determine the interface relationships between the physical components and the attributes of the physical components. For example, the brake pedal signal can be mapped to the brake pedal and brake pedal sensor in the physical components.

[0147] The present invention analyzes the corresponding physical components based on the braking logic process related to safety and security, such as Figure 10 As shown in the module definition diagram, around the vehicle controller component, in the case of manual active braking, the responsive inputs include a brake pedal sensor, an accelerator pedal sensor, a steering wheel angle sensor, and a wheel speed sensor. The outputs are connected to the motor, the power system, the four-wheel braking system, the four-wheel suspension system, the steering rudder, etc. Among them, the motor receives power supply from the power system and generates electricity through the regenerative braking system during the braking process, which is transmitted to the power system. At the same time, the motor transmits power to the four wheels through the gearbox, and the front wheels control the direction through the steering rudder. Each wheel sensor is fixed in the wheel, and the wheels are connected to the vehicle frame through the suspension system, thereby realizing the construction of the physical architecture model.

[0148] Figure 11 The schematic diagram of fault tree modeling is shown. For the fault problems during the braking process, the modeling and analysis of fault tree analysis can be carried out in the case, a simple two-state fault tree is established, the top event layer of the fault is obtained through the mission task, and the intermediate event layer and the bottom event layer are obtained through the logical architecture and the physical architecture.

[0149] Such as Figure 11 In it, the top event is that A1 braking is insensitive, the fault intermediate events B1 with debris in the cylinder block or oil pipe, B2 system wear, B3 pedal connection fault, B4 brake fault, which lead to system faults, and the fault bottom events X1 with debris in the cylinder block or oil pipe, X2 serious loss of the piston and sealing ring of the master cylinder, X3 serious loss of the piston and sealing ring of the wheel cylinder, X4 loose joint between the master cylinder and the oil pipe, X5 out-of-control displacement of the foot pedal, X6 too small pulling force of the return spring, X7 fault of the brake clearance repair device, X8 poor contact of the brake disc, X9 softening and deformation of the oil pipe, which indicate the root causes of the system faults. Each layer is selected through an OR gate. Each object here contains a probability attribute, and each object node has only two states, occurring and not occurring. For example, the occurrence probability of the object X5 out-of-control displacement of the foot pedal is 0.992509, and the non-occurrence probability is 0.007491. The occurrence probability of the object X6 too small pulling force of the return spring is 0.986591, and the non-occurrence probability is 0.013409. Therefore, through the OR gate, the occurrence probability of the object B3 pedal connection fault is the probability of either X5 or X6 occurring. Through the solution of the calculation engine, the occurrence probability of insensitive braking can be obtained.

[0150] Through the construction of more scenarios and multiple rounds of iteration of mission analysis, operation analysis, feature and function analysis, logical analysis, and physical architecture analysis, the architecture design of intelligent electric vehicles can be finally achieved, verifying the model consistency and integrity of complex systems constructed by the multi-view unified modeling language. At the same time, designers at each stage of this modeling process construct models in the same environment, ensuring a single data source. Data is transmitted through consistent standards, facilitating model interaction at each stage and collaboration among architecture designers, verifying the integration of the architecture model in multiple stages of the complex system lifecycle and improving design efficiency.

[0151] To achieve the unified construction of the model, it is necessary to first conduct the meta-model design of the domain-specific modeling language for intelligent electric vehicles. Figure 12 Shows the set of meta-models of the domain-specific modeling language for intelligent electric vehicles in the first embodiment of the present invention.

[0152] Further, before the mission analysis in step S302, there is also step S300, the meta-model design step of the domain-specific modeling language for intelligent electric vehicles, which uses the attribute meta-model, the role meta-model, the relationship meta-model, the point meta-model, the object meta-model, and the graph meta-model to construct the system top-level concept diagram, state transition description diagram, use case diagram, sequence diagram, package diagram, sequence diagram, internal module diagram, module definition diagram, flowchart, vehicle feature diagram, vehicle function type description diagram, fault tree analysis and verification diagram. As Figure 12 shown, Figure 12 Shows the set of meta-models of the domain-specific modeling language for intelligent electric vehicles in the first embodiment of the present invention.

[0153] The system top-level concept diagram describes mission tasks and their classifications, or scenarios, to show the main operating concepts of intelligent electric vehicles and some interesting or unique operating situations: describe the interaction between the subject architecture and its environment, and the interaction between the architecture and external systems. Its main purpose is to help domain system designers communicate and is intended to represent the ideas of common decision-makers. The system top-level concept diagram is simplified from the UPDM modeling language for the vehicle's system environment and contains actuator objects and dependencies, used to describe the top-level scenarios composed of the vehicle, environment, control center, signal tower, etc. The mission tasks of the present invention are relatively clear and the scenarios are well-defined. Therefore, when designing the system top-level concept diagram, the number of objects in the UPDM diagram is streamlined to design a system top-level concept for the intelligent electric vehicle scenario as Figure 13 shown. Figure 13It shows the top-level conceptual diagram description of the domain-specific modeling language meta-model system for intelligent electric vehicles, which includes an object and a relationship. Among them, the actuator object is identified by a rectangular diagram. When modeling, the background diagram of the actuator can be replaced according to the environment of the mission task, so as to more intuitively graphically express the relationship between each other. The actuator contains two attributes, the name attribute and the actuator role attribute. The attribute value of the name attribute expresses the name of the object, and the attribute value of the actuator role attribute expresses the role of the object in the mission task scenario. For example, the name is an electric vehicle, and the attribute value of the actuator role attribute is the operation terminal. The dependency relationship is identified by a dotted line with an arrow at one end, indicating that one element (client) in the model depends on another element (provider) in the model. More precisely, the dependency relationship means that when the provider element changes, the client element may also need to change. Creating a dependency relationship between two model elements is to establish traceability between the two.

[0154] The state transition diagram describes the correspondence of activities to the time series, including the initial state, state, set node, branch node object, and transition, self-transition relationship, which is used to express the state interaction relationship between the target object and the outside.

[0155] The use case diagram describes a specific series of actions, including variant series actions and error series actions, which can be executed by a system, subsystem, or class through interaction with external objects to provide value services. In the system modeling for intelligent electric vehicles in the present invention, the use case diagram meta-model is designed to include objects such as actors, actuators, use cases, boundary systems, external systems, etc., and relationships such as inclusion, extension, association, generalization, etc., to express all interactions with the outside during the design process of intelligent electric vehicles. The use case diagram is used to describe the actors, use cases, and the relationships between them of vehicle functions. The use case diagram objects include actors, actuators, boundary systems, environmental impacts, external systems, sensors, user systems, use cases, packages, modules, system contexts; the relationships include inclusion, extension, association, generalization. The use of the use case diagram includes the following key points: 1) A use case is a service or a behavior that the system will execute; 2) Not all behaviors executed by the system are use cases. Use cases are only a subset of system behaviors, which are behaviors that external actors can directly trigger or participate in; 3) An actor can be a person or an external system; 4) The actor who triggers a use case is called the main actor; 5) Each use case should represent the purpose of the main actor; 6) The use case name does not convey a large amount of information. The use case diagram is a black-box view of the system, so it is also very suitable as a context diagram of the system.

[0156] The package diagram describes the organization of the system model. The organization of the system model is determined by the hierarchical relationship of packages, and the hierarchical relationship of packages distributes the elements in the model into logically closely related diagrams. In the present invention, by setting the decomposition or sectional view mode for package objects, the package objects can be directly associated with the diagrams at the next level. In other words, a package is a container for a series of named objects. The package diagram designed in the present invention includes two objects, namely, a package and a model, and two relationships, namely, package import and element import, to describe the structural relationship in the intelligent electric vehicle system.

[0157] The sequence diagram describes the dynamic behavior information of the system, illustrates the sequence of behaviors and time occurring over time, and each part of the module will interact with each other through operation calls and asynchronous signals to generate emergent behaviors; it illustrates the sequence of behaviors and time occurring over time, and each part of the module will interact with each other through operation calls and asynchronous signals to generate emergent behaviors. The sequence diagram is used to describe the interaction between object instances in the vehicle system, and models these interactions as message exchanges. The sequence diagram objects include client ports, lifelines, and actuators; the relationships include messages. The sequence diagram of the present invention includes objects such as client ports, lifelines, and actuators and message relationships. We can use the lifeline element to model the actuators in the system behavior, and then use the messages between the lifelines to model the interactions between those actuators.

[0158] The internal module diagram describes the internal structure of a specified single module, which is a static view of the system or a component of the system. The internal module diagram does not contain module objects, but is used to show a legal configuration of a certain module - a specific series of connections between module attributes. The internal module diagram includes objects such as value attributes, composition attributes, constraint attributes, and reference attributes, and relationships such as connectors and binding connectors. The internal module diagram will show how the components of the module must be combined to create a valid instance, and will also show how the instance of the module must be connected to external entities to create a valid instance of the system as a whole. The internal module diagram is a static view of the vehicle system or a component of the system. The internal module diagram objects include value attributes, composition attributes, reference attributes, constraint attributes, flow attributes, participation attributes, binding references, and class behavior attributes; the relationships include connectors, binding connectors, project flow connectors, and project flow binding connectors.

[0159] The module definition diagram describes the structure of the system, including objects such as modules, flow specifications, systems, system contexts, value types, etc., and relationships such as associations, generalizations, aggregations, etc. We need to regard the systems, subsystems, devices, etc. of intelligent electric vehicles as collections of objects at different levels such as modules, and then combine each module through connection methods such as associations to form the overall architecture of the intelligent electric vehicle. The module definition diagram is used to define the structure of the vehicle system. The objects of the module definition diagram include packages, modules, interface modules, flow specifications, constraint modules, domain modules, subsystems, external modules, systems, system contexts, value types, quantity types, units; the relationships include interface implementation, link, association block, directed association, association, directed aggregation, aggregation, directed composition, composition, generalization, usage, project flow.

[0160] The flowchart described above depicts the business process operations, aiming to provide a simple mechanism when creating a business process model while being able to handle the complexity arising from the business process. The flowchart of the present invention refers to the BPMN2.0 specification and includes objects such as tasks, service tasks, subprocesses, call activities, etc., and relationships such as sequence flows, data associations, etc., which are used to support the development of various business processes of intelligent electric vehicles. The flowchart is used to describe the relevant design processes of the vehicle. Its objects include tasks, service tasks, send tasks, receive tasks, user tasks, manual tasks, business rule tasks, script tasks, subprocesses, transaction subprocesses, specific subprocesses, call activities, start events, information start events, timer start events, error start events; the relationships include sequence flows, data associations.

[0161] The vehicle feature diagram describes the features of vehicles at the vehicle level, that is, it shows "what is a vehicle?" through various features. For example, a vehicle is composed of features such as "motor, body, chassis, electrical equipment", and the various variants of the vehicle may have or may not have certain features. The vehicle feature diagram of the present invention refers to the EAST-ADL modeling specification and includes objects such as vehicle features, general constraints, functional design prototypes, user attribute elements, etc., and relationships such as feature combinations, satisfaction, etc., which are used to express the development of the embedded electronic architecture in aspects such as vehicle power control and perception. The vehicle feature diagram describes vehicle features. Its objects include general constraints, requirements, annotations, quality requirements, EA types, vehicle features, design function prototypes, user attribute elements, analysis function prototypes, features, hardware component prototypes; the relationships include annotations, implementation, satisfaction, feature combinations, and feature links.

[0162] The vehicle function type diagram describes the functional analysis architecture of the vehicle. The vehicle function type diagram of the present invention refers to the EAST-ADL modeling specification and includes objects such as flow inlets, flow outlets, analysis function prototypes, general constraints, etc., and relationships such as flows, satisfactions, annotations, etc., for expressing the functional analysis of the vehicle feature model. The vehicle function type diagram describes the vehicle functions, and its objects include flow inlets, flow outlets, general constraints, requirements, annotations, client ports, power ports, server ports, quality requirements, user attribute elements, inflow and outflow ports, analysis function prototypes; the relationships include client-server interfaces, annotations, assignments, implementations, derived requirements, satisfactions, power supplies, flows.

[0163] The fault tree analysis and verification diagram describes system failure problems and finds the root causes of faults through calculations to reduce risks. The fault tree analysis and verification diagram of the present invention includes objects such as fault top events, fault bottom events, OR gates, AND gates, etc., and relationships such as evaluations, references, etc. By analyzing the brake failure, the fault impacts corresponding to the fault modes are obtained. The fault tree analysis and verification diagram is implemented by referring to the FTA fault tree analysis method model, and its objects include fault intermediate events, other events, hazard event classifications, OR gates, AND gates, fault bottom events, vehicle complete integrity levels, fault top events; the relationships include references, evaluations, constraints.

[0164] Figure 14 The file resources of the meta-model constructed specifically for the intelligent electric vehicle with respect to the modeling language are shown. Through the construction of each meta-model in the figure, a domain-specific modeling language for the intelligent electric vehicle is jointly formed. Through the construction of this meta-model library, a modeling environment from mission tasks to physical architectures is provided, ensuring the integration of multiple modeling languages throughout the life cycle.

[0165] The graphic meta-model mainly includes module definition diagrams, use case diagrams, flowcharts, vehicle feature diagrams, vehicle function type diagrams, etc. Here, the module definition diagram is used to describe any entity in the intelligent electric vehicle system, the use case diagram is used to describe the actors and use cases of the vehicle functions and the relationships between them, the flowchart is used to describe the relevant design processes of the vehicle, the vehicle feature diagram is used to describe vehicle features, design functions, general constraints, etc., and the vehicle function type diagram is used to describe the vehicle function-related components such as vehicle function inlets, vehicle function outlets, power ports, and server ports.

[0166] The point meta-model mainly includes input / output ports of flows, software I / O input / output ports, input / output ports of power hardware pins, etc. The input / output ports of flows define the attributes such as the input / output interface attributes and positions of the control flow, the software I / O input / output ports define the ports for information exchange between the vehicle host and the controlled object, and the input / output ports of power hardware pins define the port information of the vehicle power system hardware-related pins.

[0167] The relationship meta-model mainly includes satisfaction, feature combination, derivation, association, etc. The satisfaction relationship is an assertion indicating that the instances of the client module meet the requirements of the provider module. The feature combination relationship defines the combination relationship of vehicle features. The derivation relationship describes the relationship of new modules obtained based on the original defined modules. The association relationship represents a connection existing between the instances of vehicle system modules.

[0168] The role meta-model serves the relationship meta-model and mainly includes a satisfaction terminal, a satisfaction start-end, an implementation terminal, an implementation start-end, a feature combination terminal, a feature combination start-end, a derivation terminal, a derivation start-end, an association terminal, an association start-end, etc. The role meta-model is configured within the relationship meta-model to implement the performance of the relationship. The object meta-model mainly includes vehicle features, quality requirements, power ports, interface modules, domain modules, etc. The vehicle feature object is used to instantiate vehicle features. The quality requirement object is used to instantiate the requirements related to vehicle quality. The power port object is used to instantiate a specific power port, which can contain more attribute information. The interface module object contains the attributes of complex interfaces and is thus independent of the interface port. The domain module object classifies the vehicle system from multiple perspectives, such as the control domain, the body domain, etc.

[0169] The attribute meta-model mainly includes name, vehicle integrity level, feature parameters, cardinality, cost, components, actuator roles, etc., and is used to configure other meta-models such as the object meta-model and the relationship meta-model. For example, configuring name attributes, feature parameter attributes, cardinality attributes, etc. for feature objects to form a complete expression of feature objects.

[0170] The "module" and "unit" in this specification refer to software and / or hardware that can independently complete or cooperate with other components to complete specific functions. Among them, the hardware can be, for example, FPGA (Field-Programmable Gate Array), IC (Integrated Circuit).

[0171] The present invention also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, it implements the steps of the above-mentioned modeling method based on the multi-view unified modeling language. Among them, the computer-readable storage medium can include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, micro drives, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nano-systems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0172] The present invention also provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that when the processor executes the program, the steps of the above-mentioned modeling method based on the multi-view unified modeling language are implemented. In the embodiments of the present invention, the processor is the control center of the computer system, which can be the processor of a physical machine or the processor of a virtual machine.

[0173] The above introduction is only the preferred embodiment of the present invention, and does not impose any substantial and formal limitations on the present invention. Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. For those skilled in the art, within the scope of the technical solution of the present invention, various effective embodiments of changes and modifications can be made using the above-disclosed technical content. Any simple modification, equivalent replacement, and improvement made to the above embodiments based on the technical essence of the present invention without departing from the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A modeling system based on the multi-view unified modeling language, characterized in that: it includes an attribute meta-model construction unit, a role meta-model construction unit, a relationship meta-model construction unit, a point meta-model construction unit, an object meta-model construction unit, and a graph meta-model construction unit; among them, The attribute meta-model construction unit is used to construct an attribute meta-model, and the attribute meta-model is used to define the attribute type, identified by the keyword "Property". After being inherited, the attribute meta-model becomes the attribute of other meta-model elements; The role meta-model construction unit is used to construct a role meta-model, and the role meta-model is used to define how the object type connects to the relationship type, identified by the keyword "Role". The relationship will indirectly associate objects on the role; the role meta-model is configured in the relationship meta-model to implement the performance of the relationship; The relationship meta-model construction unit is used to construct a relationship meta-model, and the relationship meta-model is used to define the connection relationship between object meta-models, identified by the keyword "Relationship"; The point meta-model construction unit is used to construct a point meta-model, and the point meta-model is used to provide additional semantics or constraints on how objects are connected through relationships, instantiated by the unique identifier "pointSystemName"; the point meta-model includes input and output ports of the flow, software I / O input and output ports, and power hardware pin input and output ports. The input and output ports of the flow define the input and output interface attributes and location attributes of the control flow. The software I / O input and output ports define the ports for information exchange between the vehicle host and the controlled object. The power hardware pin input and output ports define the port information of the hardware-related pins of the vehicle power system; The object meta-model construction unit is used to construct an object meta-model, and the object meta-model is used to define a group or a class of elements with the same characteristics, instantiated by the unique identifier "objectSystemName"; The graph meta-model construction unit is used to construct a graph meta-model, and the graph meta-model includes the organization of object meta-models and relationship meta-models, the definition of bindings, and the definition of decomposition and sectional view modes, identified by the keyword "Partial".

2. The modeling system based on the multi-view unified modeling language according to claim 1, characterized in that the attribute meta-model has the following characteristics: Dependence: The attribute depends on other elements in the meta-model and cannot be instantiated alone. It can be inherited in other elements; Diversity: The same attribute meta-model can be inherited by different meta-model elements to express different attribute meanings; Uniqueness: When the meta-model attribute contains the keyword "unique", the value of this attribute in the instantiated model containing this meta-model is unique; Orderliness: When the number of meta-model attributes of the same meta-model or model attributes of the model is greater than 1, requirements can be made on the order of the attributes; Initial value: When the meta-model attribute contains the keyword "initial", an initial value can be assigned to the meta-model attribute, and the initial value can be an integer type, a real number type, or a string.

3. The modeling system based on the multi-view unified modeling language according to claim 1, It is characterized in that: The role meta-model is instantiated by a unique identifier roleSystemName. The direction of the RType role and the relationship define the data flow direction or the relationship transmission direction by declaring the types and directions of the roles at both ends. The directions include the start-end Import and the end-end Export. The role containing Import is the data entry, and the role containing Export is the data exit.

4. A modeling system based on the multi-view unified modeling language according to claim 1, It is characterized in that: The connection relationships include satisfaction, feature combination, derivation, and association. The satisfaction relationship is an assertion indicating that the instance of the client module meets the requirements of the provider side; The feature combination relationship defines the combination relationship of vehicle features; The derivation relationship indicates the relationship of the new module obtained on the basis of the original defined module. The association relationship represents a connection existing between the instances of the vehicle system modules.

5. A modeling system based on the multi-view unified modeling language according to claim 1, It is characterized in that: The point meta-model has the following characteristics: Dependency. The point meta-model can be defined independently, but the point model must exist depending on the object model; Diversity. Multiple point models can be added to the object model, and the direction of the point model is not restricted; Multiplicity. Each point model on the object model can be bound to multiple role models, or each object model can be connected to multiple relationship models through the point model.

6. A modeling system based on the multi-view unified modeling language according to claim 1, It is characterized in that: The object meta-model includes vehicle features, quality requirements, power supply ports, interface modules, and domain modules. The vehicle feature object is used to instantiate vehicle features. The quality requirement object is used to instantiate vehicle quality-related requirements. The power supply port object is used to instantiate a specific power supply port, which can contain multiple attribute information. The interface module object includes the attributes of the interface. The domain module object is the classification of the vehicle system from multiple perspectives, including the control domain and the body domain.

7. A modeling system based on the multi-view unified modeling language according to claim 1, It is characterized in that: The graph meta-model determines the basic composition of the graph by declaring the object meta-model class and the relationship meta-model class; The keyword Constraint() represents a constraint, allowing the definition of additional conditions for the meta-model elements, and the conditions must be met during or after modeling; Among them, it includes a binding constraint: bindconnector() establishes the constraint relationship between the object and the relationship; And The specification of decomposition and sectioning: decompose represents decomposition, supporting the refinement of object, point, and relationship elements, and expanding an element into a graph for detailed description.

8. A modeling method based on the multi-view unified modeling language, It is characterized in that, It includes the following steps: Construct an attribute meta-model. The attribute meta-model is used to define the attribute type, identified by the keyword Property. The attribute meta-model is inherited and becomes the attribute of other meta-model elements; Construct a role meta-model, which is used to define how object types connect to relationship types, identified by the keyword Role. Relationships will indirectly associate objects on roles. The role meta-model is configured within the relationship meta-model to implement the performance of relationships. Construct a relationship meta-model, which is used to define the connection relationships between object meta-models, identified by the keyword Relationship. Construct a point meta-model, which is used to provide additional semantics or constraints on how objects are connected by relationships, instantiated by the unique identifier pointSystemName. The point meta-model includes input and output ports for flows, software I / O input and output ports, and power hardware pin input and output ports. The input and output ports for flows define the input and output interface attributes and location attributes of control flows. The software I / O input and output ports define the ports for information exchange between the vehicle host and controlled objects. The power hardware pin input and output ports define the port information for pins related to the vehicle power system hardware. Construct an object meta-model, which is used to define a group or class of elements with the same characteristics, instantiated by the unique identifier objectSystemName. Construct a diagram meta-model, which includes the organization of object meta-models and relationship meta-models, the definition of bindings, and the definition of decomposition and sectional view modes, identified by the keyword Partial.

9. A modeling method based on the multi-view unified modeling language as claimed in claim 8, characterized in that: It further includes the following steps: Mission analysis, complete the mission task analysis of the intelligent transportation system scenario through the system top-level concept diagram to obtain potential design solutions. Operation analysis, for the intelligent electric vehicle in the intelligent transportation system, use the state transition diagram to conduct operation concept analysis on the intelligent electric vehicle as the target system. By analyzing the life cycle of the intelligent electric vehicle system, determine the starting point of system analysis and define candidate operation concept solutions for the mission. Feature and function analysis, conduct feature modeling of the intelligent electric vehicle through the vehicle feature diagram to achieve function analysis of speed control and intelligence in the driving scenario of the intelligent electric vehicle. Logic analysis, describe the operation behavior changes of the braking system through the logical architecture, and analyze all the logical architectures involved in the braking process and the functional flows and interactions between them through the sequence diagram. Physical architecture analysis, determine the physical components corresponding to the objects in the logical model and their quantities, determine the connection relationships between physical components and the attributes of physical components, and finally form the physical architecture.

10. A modeling method based on the multi-view unified modeling language as claimed in claim 9, characterized in that: Before the mission analysis step, it further includes a meta-model design step of the domain-specific modeling language for intelligent electric vehicles. The system top-level concept diagram, state transition description diagram, use case diagram, sequence diagram, package diagram, sequence diagram, internal module diagram, module definition diagram, flow chart, vehicle feature diagram, vehicle function type description diagram, fault tree analysis and verification diagram are constructed by using the attribute meta-model, the role meta-model, the relationship meta-model, the point meta-model, the object meta-model, and the graph meta-model; The system top-level concept diagram describes mission tasks and their classifications, and is used to describe the interaction between the subject architecture and its environment, as well as the interaction between the architecture and external systems; The state transition diagram describes the correspondence of activities to the time series, including the initial state, states, set nodes, branch node objects and transitions, self-transition relationships, and is used to express the state interaction relationship between the target object and the outside; The use case diagram describes a specific series of actions, including variant series of actions and error series of actions, which can be executed by a system, subsystem or class through interaction with external objects to provide value services; The package diagram describes the organization method of the system model. The organization method of the system model is determined by the hierarchical relationship of packages, and the hierarchical relationship of packages distributes the elements in the model into logically closely related diagrams; The sequence diagram describes the dynamic behavior information of the system, illustrates the behavior and time sequence that occur over time, and each part of the module will interact with each other through operation calls and asynchronous signals to generate emergent behavior; The internal module diagram describes the internal structure of a specified single module, which is a static view of the system or a component of the system, and is used to show a specific series of connections between the attributes of a certain module. The internal module diagram includes value attributes, composition attributes, constraint attributes, reference attribute objects and connectors, and binding connector relationships; The module definition diagram describes the structure of the system, including modules, flow descriptions, systems, system contexts, value type objects and associations, generalizations, and aggregation relationships; The flow chart describes business process operations, and is designed to provide a simple mechanism when creating a business process model, while being able to handle the complexity from the business process; The vehicle feature diagram describes the features of vehicles at the vehicle level; The vehicle function type diagram describes the functional analysis architecture of the vehicle; The fault tree analysis and verification diagram describes system failure problems, and finds the cause of the fault through calculation to reduce risks.

Images