A modeling and model conversion method for autonomous driving demand analysis

Abstract

The application provides a modeling and model conversion method for automatic driving demand analysis, comprising the following steps: step 1, defining a UML extension meta-model; step 2, obtaining an intermediate model; and step 3, generating a target extension model. The application combines the abstracted concepts with the UML analysis model by analyzing and extracting the automatic driving related terms and concepts and the behavior characteristics of the automatic driving vehicle, realizes the extension of the UML class diagram and the activity diagram in the automatic driving field, formulates the model conversion rules according to the automatic driving concepts of the automatic driving system limited use case modeling language, and realizes the model conversion method based on the model conversion engine written in the Java language, so that the defects that the general model conversion method cannot process the RUCM4ADS model are made up, the efficiency and accuracy of the model conversion in the automatic driving field are promoted, the subsequent analysis and testing of the system demand are facilitated, and the accuracy of the demand modeling in the automatic driving field is improved.

Description

Technical Field

[0001] This invention belongs to the field of demand modeling and transformation, and in particular relates to a modeling and transformation method for demand analysis of autonomous driving. Background Technology

[0002] Model-driven development (MDD) is a mature software development methodology. The model is the core of MDD and has a wide range of applications, such as model transformation and model analysis. Model transformation is the core of Model-Driven Engineering (MDE), and its application drives the automation of MDE. It has a wide range of applications and high research value. Model transformation refers to the method of generating a target model or target text from a source model through a metamodel. Its methods and tools can be used to develop, transform, compare, and validate models and metamodels. For example, it can be used to validate models using formal methods, transform models into target models to facilitate the analysis of source models, and generate subsequent test cases.

[0003] A domain is a specific area or industry with specific concepts, relationships, constraints, and domain knowledge. Domain-specific software development requires targeted methods and tools to facilitate the development process, such as in medical, military, and biological fields. Autonomous driving is an emerging field that has attracted significant attention from the artificial intelligence and automotive industries in recent years. Autonomous vehicles are a focal point in this field. Due to the inherent intelligence of autonomous vehicles, the uncertainty of the external environment, and the potential for major disasters caused by software system failures, the design and development of autonomous driving systems are particularly important. Requirements analysis is a crucial step in the software development lifecycle. Currently, there are many frameworks for analyzing and describing autonomous driving requirements, such as the Wise Drive method and the Restricted Use Case Modeling Method for Autonomous Driving Systems (RUCM4ADS) proposed by the Intelligent Systems Engineering Laboratory at the University of Waterloo, Canada. RUCM4ADS is an emerging use case modeling method specific to the autonomous driving domain, extending the Restricted Use Case Modeling Method (RUCM). By adding specific concepts, attributes, and terminology from the autonomous driving domain, it can specifically describe autonomous driving use case scenarios. Implementing model conversion of RUCM4ADS models is helpful for the analysis of autonomous driving scenarios and the testing of autonomous driving systems, and is a problem worthy of research.

[0004] Atoucan is a model conversion method that transforms general restricted use case models into UML analysis models (such as activity diagrams, class diagrams, and sequence diagrams) to facilitate structured analysis and verification of RUCM requirement models, further converting them into test cases for execution, and ultimately standardizing system requirements. However, this method lacks processing of the RUCM4ADS metamodel, and the elements of the target UML analysis model cannot fully cover the professional concepts and elements in the autonomous driving field. Addressing the current lack of conversion methods for use case scenario requirements described by RUCM4ADS, this invention analyzes the autonomous driving-related terms and concepts introduced in the RUCM4ADS restricted use case modeling method for autonomous driving systems, as well as the characteristics of autonomous vehicle actions. It extends the UML analysis model to the autonomous driving domain and proposes a conversion method from the RUCM4ADS restricted use case modeling method to the extended UML analysis model. This improves the efficiency and accuracy of model conversion in the autonomous driving field, aids in subsequent system requirement analysis and testing, and ultimately enhances the accuracy of autonomous driving requirement modeling. The extended UML metamodel can be used to construct autonomous driving requirement models and to capture autonomous driving scenario elements in the source model (RUCM4ADS model) during the model conversion process. Summary of the Invention

[0005] Purpose of the invention: This invention proposes a modeling and model conversion method for autonomous driving requirements analysis, which makes up for the current lack of conversion of use case scenario requirements described by RUCM4ADS. By extending the UML model to autonomous driving, the domain professionalism and accuracy of the model conversion process are improved, which promotes the subsequent analysis and testing of system requirements. In addition, the extended meta-model can be used to model autonomous driving requirements.

[0006] Technical Solution: This invention provides a modeling and model conversion method for autonomous driving requirements analysis, including the following steps:

[0007] Step 1: Based on the Wise Drive autonomous driving requirements standard and autonomous driving system functional architecture, define the UML extended metamodel; the UML extended metamodel is used to construct the autonomous driving requirements model and to capture autonomous driving scenario elements in the source model (RUCM4ADS model) during the model transformation process;

[0008] Step 2: Import the autonomous driving scenario model RUCM4ADS, and parse the autonomous driving scenario model RUCM4ADS to obtain the intermediate model UCM4ADS. UCM4ADS defines a series of meta-models to record the information obtained from parsing; specifically, it includes identifying the Actors related to the autonomous driving environment in the model use case template, parsing the event flow defined in the use case template, and applying a natural language parser (Stanford parser) to parse the event statements in the event flow.

[0009] Step 3: Apply customized model transformation rules to the intermediate model to generate the target UML extended model. The customized model transformation rules include transformation rules for generating class diagrams and activity diagrams.

[0010] Step 1 includes: referencing the Wise Drive standard and the functional architecture of autonomous driving systems, abstracting a domain conceptual model, and combining the domain concepts with the UML metamodel to extend the UML model: based on the UML lightweight extension mechanism (Profile extension mechanism), extending the UML class diagram and activity diagram for the autonomous driving domain; in terms of the class diagram, defining ADSActor and specific participants to describe individuals in the autonomous driving scenario, defining Condition to describe the vehicle and environmental states in the autonomous driving scenario, and refining and extending the UML metamodel element Association; in terms of the activity diagram, extending CallBehaviorAction to describe three different levels of autonomous driving use case activities, and extending CallOperationAction to capture the system behavior of the autonomous driving system in four aspects: perception, planning, decision-making, and control. Wise Drive is a framework proposed by the University of Waterloo for analyzing and describing the behavioral requirements of autonomous driving, providing concepts and methods for defining and analyzing Dynamic Driving Task (DDT), Road Environment, and Driving Quality in an autonomous driving environment.

[0011] The functional architecture of an autonomous driving system is a concept described in the ISO 26262 functional safety standard [~], which includes the perception module, control module, planning module, and decision module.

[0012] In step 1, defining ADSActor and specific actors in the class diagram to describe individuals in the autonomous driving scenario specifically includes:

[0013] The Wise Drive standard defines the driving environment ontology, defining ADSActor and specific environmental participants, namely the natural environment, roads, animals, human participants, and entities. The specific definitions are as follows:

[0014] The natural environment refers to the natural environment portion of the driving environment, including natural attributes such as weather, temperature, and visibility.

[0015] The road refers to the road conditions under autonomous driving scenarios, including road structure and surface conditions.

[0016] The animals mentioned refer to animals in the scenario that may affect vehicle driving behavior, including attributes such as animal species and size.

[0017] The human participants are categorized into vehicle users and road users based on their different usage types. Given the diversity of road participants in the scenario, road users are further divided into pedestrians, traffic controllers, and animal riders.

[0018] The term "entity" refers to entities other than humans in an autonomous driving scenario, including vehicles and other obstacles.

[0019] In step 1, the defined Condition describes the vehicle and environmental state in an autonomous driving scenario. Specifically, in an autonomous driving environment, besides the multiple participants involved in the driving task, it also includes vehicle or environmental conditions. Vehicle or environmental conditions can be divided into two categories: one is the vehicle and its associated environmental attributes, such as vehicle speed, distance to the vehicle in front, traffic lights, etc.; the other is the dynamic behavioral state of environmental participants (vehicles or road users), such as the vehicle maintaining speed, the vehicle in front changing lanes, etc. Based on the above situations, a derived state (Condition) is defined to describe the autonomous driving scenario state, specifically extended to vehicle or environmental activity state and vehicle-related attribute state. The vehicle or environmental activity state includes attributes recording specific activities, and the vehicle-related attribute state includes two attributes: name and value.

[0020] Step 1, which involves refining and expanding the UML metamodel element Association, specifically includes:

[0021] The UML metamodel element Association primarily represents a relationship between classes. In the context of autonomous driving, it represents the relationship between autonomous vehicles or systems and external vehicles, pedestrians, and the environment. Based on the analysis of autonomous driving functional architecture, four types of autonomous driving relationships are defined: control, decision-making, perception, and general behavior relationships.

[0022] In step 1, the activity graph is extended to CallBehaviorAction to describe three different levels of autonomous driving use case activities, specifically including:

[0023] The autonomous driving constrained use case modeling language RUCM4ADS divides autonomous driving use cases into control use cases, manipulation use cases, and policy use cases based on the three-layer autonomous driving task described in the Wise Drive autonomous driving requirements framework. On this basis, the CallBehaviorAction metamodel is extended to three activities to capture scenario use cases at different levels in the RUCM4ADS model, namely control behavior activities, manipulation behavior activities, and policy behavior activities.

[0024] In step 1, the CallOperationAction is extended to capture the system behavior of the autonomous driving system in four aspects: perception, planning, decision-making, and control. Specifically, this includes:

[0025] The UML metamodel CallOperationAction is used to describe the behavior of use case actors. It refers to the autonomous driving tasks described in Wire Drive and the autonomous driving function system architecture in the ISO26262 functional safety standard. It also analyzes more than 150 system activities in 46 autonomous driving scenario use cases described by the RUCM4ADS tool. CallOperationAction is extended in three aspects: perception, planning and control.

[0026] Perception aspect: Perception includes the perception of the vehicle itself and the external environment (e.g., roads, traffic lights, road users). Therefore, a derivative perception activity, `CallPerceptionAction`, is defined to describe the system's perception actions. This derivative perception activity is further divided into state perception activities, `CallConditionDetectAction`, and behavior perception activities, `CallBehaviorDetectAction`. State perception activities represent the system's perception actions regarding states, including the perception behavior of object states (e.g., the speed of the vehicle itself or the vehicle in front, the color of traffic lights) and the relationship between the vehicle and external objects (e.g., the distance between the vehicle itself and the vehicle in front). Behavior perception activities describe the perception actions of object movement or intention, such as changing lanes, crossing the road, overtaking, etc.

[0027] Planning: Planning refers to the system's planning and decision-making based on perceived data information, and is a core function of autonomous driving systems. Based on the analysis of more than 150 autonomous driving system behaviors in 46 ADS scenarios modeled by RUCM4ADS, planning activities (CallPlanAction) and decision-making activities (CallDecisionAction) are defined. The planning activity (CallPlanAction) is further divided into task planning activities (CallMissonPlanAction) and motion planning activities (CallMotionPlanAction). The task planning activity describes a planned action, which is a comprehensive optimal plan from the current position to the target position; the motion planning activity describes the planned actions of vehicle motion behavior and trajectory. Autonomous driving system decisions affect the vehicle, which is reflected in changes in vehicle state and behavior. Therefore, the decision-making activity is further extended into state decision-making activities (CallVariableDecisionAction) and behavior decision-making activities (CallBehaviorDecisionAction). The two derived classes include variables and behavioral attributes to capture the state values ​​and specific behaviors of system decisions.

[0028] In terms of control, within the architecture of an autonomous driving system, control refers to the low-level trajectory control of the main vehicle (such as longitudinal and lateral control) and the control activities directly performed on vehicle equipment. Therefore, a derivative control activity, `CallControlAction`, is defined. This derivative control activity is further divided into behavior control activities (`CallBehaviorControlAction`) and vehicle actuator control activities (`CallActuatorControlAction`). Behavior control activities represent the control behaviors by which the autonomous driving system controls the main vehicle to maintain or complete driving tasks. These control behaviors are strategic (e.g., the system controls the main vehicle to return to its original lane) or directly reflected in the vehicle's trajectory (e.g., the system controls the main vehicle to turn left). Vehicle actuator control activities capture the control operations of the system on vehicle actuators (such as motors, lights, brakes, and steering), such as the system controlling the target vehicle to turn on its turn signals.

[0029] In step 2, the autonomous driving scenario model RUCM4ADS includes scenario actors (such as cars, pedestrians, and drivers) and autonomous driving scenario use case descriptions. Autonomous driving scenario use cases describe all the behavioral activities of the system vehicle to complete a specific scenario task. Its core is the use case template, which includes various types of elements, including preconditions, primary actors, road participants, vehicles, road users, and basic, alternative, and global event flows. The intermediate model UCM4ADS is used to store the information obtained from model parsing and defines the following meta-models: SentenceStructure, SentencePatterns, and SentenceSemantic.

[0030] Step 2 specifically includes:

[0031] Step 2-1, parsing the RUCM4ADS model elements, specifically includes the following steps:

[0032] Step 2-1-1: Analyze the Actor concept elements in the RUCM4ADS model, such as vehicles, roads, and pedestrians;

[0033] Step 2-1-2: Analyze the autonomous driving scenario use cases (ADS Use Cases) contained in the RUCM4ADS model, specifically including the following steps:

[0034] Step 2-1-2-1: Obtain the actors included in each scenario use case, including elements such as road users, vehicles, and the natural environment.

[0035] Step 2-1-2-2: Process the three event flows within the scenario use cases. Each event flow includes an event list and a post-condition. The event list is a collection of events, and each event is represented by a meta-model Sentence, representing a participant's action. Sentences have different generics, including SimpleSentence, ComplexSentence, and SpecialSentence. Simple sentences refer to statements described in natural language, complex sentences refer to statements including Condition, Iterator, Meanwhile, and Validate, and special sentences specify the relationships between events in use cases. For example, ResumeSentence contains the keyword RESUME STEP n, used to jump from the current event flow to the nth step of the basic event flow. The processing of the event flow involves processing the three different event statements. The specific parsing process includes the following steps:

[0036] Step 2-1-2-2-1: If the statement is a special statement, identify the keywords to determine the specific statement type, and then determine the event flow step or other scenario use case. For example, the RESUME STEP 5 statement identifies step 5, and the INCLUDE USECASE Maintain lane statement identifies the external scenario use case Maintain lane.

[0037] Step 2-1-2-2-2: If the statement is a complex sentence, identify keywords to determine the statement type. For example, the IF ELSE keyword indicates that the sentence is a conditional statement. Then extract the simple statements inside and proceed to step 2-1-2-2-3 for processing.

[0038] Step 2-1-2-2-3: If the sentence type is a simple sentence, use the natural language processing technology StandordParser for processing, including word segmentation, part-of-speech tagging, and dependency parsing. During this process, determine the sentence structure, including subject, predicate, object, and complement. Further identify the sentence type (SentencePatterns) based on the sentence structure. The intermediate model UCM4ADS defines multiple sentence types, including subject-predicate SV, subject-predicate-object SVDO, and subject-predicate-object-complement SVDOC. Finally, identify the semantic structure of the sentence based on the meaning of the subject and object, such as receiving information, validation, and internal transaction.

[0039] Step 2-2: Initialize the intermediate model instance UCM4ADS based on the scene actors and event flow statements identified in Step 2-1, the sentence types and sentence semantic structures parsed from the natural language statements.

[0040] In step 3, the conversion rules for generating class diagrams are used to convert the intermediate model into a UML extended class diagram, including:

[0041] Rule b1: Identify class entities from possessive or non-possessive noun phrases (NPs);

[0042] Rule b2: Identify class entity attributes, operations, and relationships between class entities by analyzing description strings with noun phrases before or after them;

[0043] Rule b3: Based on the sentence type (such as SVDO, SVIODO, SWDOC, etc.), apply mapping rules to generate the attributes, operations, and associations between corresponding class entities;

[0044] The conversion rules for generating activity diagrams are used to convert intermediate models into UML extended activity diagrams, specifically including:

[0045] Rule c1: Generate a UML activity diagram for each autonomous driving scenario use case in the RUCM4ADS model;

[0046] Rule c2: For the precondition and postcondition in the autonomous driving scenario use case, form an instance of a constraint, and add the instance to the initial node or the terminating node of the activity graph.

[0047] Rule c3: Apply mapping rules to process simple, complex, and special sentences in the event flow of the RUCM4ADS use case model;

[0048] Rule c4: Generate an instance of AcceptEvent and InterruptbieActivityRegion for each global event candidate stream, and apply rule c3 to process sentences in the event stream;

[0049] Rule c5: Based on the SentenceSemantic structure obtained during the model parsing phase, the system data flow interaction type is defined, and an input Pin or output Pin is generated for each CallOperationAction; wherein the system data flow interaction types include: the system receiving data or information, the system verifying a request or data, and the system modifying internal values; compared with the prior art, the present invention has the following beneficial effects:

[0050] 1. This invention analyzes the autonomous driving environment and tasks, extracts autonomous driving concepts and relationships, summarizes the functions and vehicle behaviors of autonomous driving systems, and introduces these concepts into the UML modeling language. Based on the UML Profile extension mechanism, the UML model (class diagram and activity diagram) is extended to the autonomous driving domain to capture detailed elements of the autonomous driving system's defined use case scenario (RUCM4ADS) model. At the same time, the extended UML model can be used to build UML autonomous driving scenario modeling tools to promote the analysis and verification of autonomous driving scenario use case requirements.

[0051] 2. This invention provides a model conversion method for RUCM4ADS, which can convert autonomous driving use case requirement models. This method implements a model preprocessing module to process RUCM4ADS model elements, defines model conversion rules to map model elements, and in detail, uses a vocabulary library to perform semantic judgment on words in RUCM4ADS scenario requirement description statements to achieve specific meta-model mapping, and finally completes the model conversion process. This method makes up for the shortcomings of the Atoucan requirement conversion method, which cannot convert RUCM4ADS models and whose model conversion rules cannot fully handle RUCM4ADS model elements. It promotes the subsequent analysis and testing of system requirements, thereby improving the accuracy of scenario requirement modeling in the field of autonomous driving. Attached Figure Description

[0052] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0053] Figure 1 This is a schematic diagram of the overall model transformation framework of the method of the present invention.

[0054] Figure 2 This is a flowchart illustrating the execution process of the method of the present invention.

[0055] Figure 3 This is a schematic diagram of the UML class diagram extension profile definition described in this invention.

[0056] Figure 4 This is a schematic diagram of the extended Profile definition for the UML activity diagram described in this invention.

[0057] Figure 5 This is a schematic diagram of the RUCM4ADS model parsing method described in this paper. Detailed Implementation

[0058] This invention proposes a model conversion method for the RUCM4ADS (Ruttorium for Autonomous Driving Systems) modeling language. Figure 1This is the overall framework of the model conversion method, comprising three aspects. The first is RUCM4ADS use case scenario modeling, which constructs use case scenario models based on modeling tools. The second is the UML extension model, which combines the autonomous driving concept defined in the Wise Drive autonomous driving requirements description framework and the RUCM4ADS metamodel of the use case modeling method. It extends UML class diagrams and activity diagrams based on the UML Profile extension mechanism, and the extended metamodel can be used for autonomous driving requirements modeling. The third is the model conversion engine, including a model parsing module and a rule mapping module. The parsing module parses RUCM4ADS template elements and uses natural language processing technology to process sentences, identifying sentence types and semantic structures, ultimately generating a UCM4ADS intermediate model. The rule mapping module converts the intermediate model into the target UML extended model by applying model conversion rules, which are divided into class diagram and activity diagram conversion rules. The following sections will detail the model extension and model conversion engine aspects, with specific implementation details as follows:

[0059] 1. Referring to the Wise Drive standard and the functional architecture of autonomous driving systems, concepts from the autonomous driving domain are extracted and combined with the UML metamodel. Based on the UML Profile mechanism, the UML model is extended. UML extensions include extensions to class diagrams and activity diagrams; specific details are as follows:

[0060] A. UML Class Diagram Extension:

[0061] Figure 3 This refers to the UML class diagram extension Profile definition. The extension points are: defining the ADSActor metaclass to capture participants in the driving environment, defining the Condition metaclass to describe autonomous driving scenario conditions, and refining and extending the UML metamodel element Association. The specific implementation process is as follows:

[0062] This method defines a driving environment ontology based on the Wise Drive standard, defining the metaclass ADSActor and specific environmental actors, namely Natural Environment, Road, Animal, HumanActor, and Object. Specific details are described below:

[0063] 1) Natural Environment refers to the natural environment portion of the driving environment, including natural attributes such as weather (clouds), temperature, and visibility.

[0064] 2) Road refers to the road conditions under autonomous driving scenarios, including road type and lane structure.

[0065] 3) Entity (Object) refers to entities other than humans in the autonomous driving scenario, including vehicles and other obstacles.

[0066] 4) Human actors are categorized into vehicle users and road users based on their usage patterns. Given the diversity of road users in the scenario, road users are further divided into pedestrians, traffic controllers, and animal riders.

[0067] 5) Animal represents animals in the scene that may affect vehicle driving behavior, including attributes such as animal type and size (height & weight). Animal type is an enumeration type, including two enumeration values: wild and domestic.

[0068] In an autonomous driving environment, in addition to multiple participants in the driving task, there are also various vehicle or environmental conditions. These conditions can be divided into two categories: one is the vehicle and environmental attribute variables related to the vehicle, such as the vehicle's speed, distance from the vehicle in front, traffic lights, etc.; the other is the dynamic behavior of environmental participants (vehicles or road users), such as the vehicle maintaining speed and the vehicle in front changing lanes.

[0069] Based on the above situations, this method defines a derived state (Condition) to describe the autonomous driving scenario, specifically extended to vehicle or environmental activity status (BehaviorCondition) and vehicle-related attribute status (VehicleCondition). Vehicle or environmental activity status includes an action attribute that records the specific activity, while vehicle-related attribute status includes two attributes: name and value.

[0070] The UML metamodel element Association primarily represents a relationship between classes. In the context of autonomous driving, it mainly involves the relationship between autonomous vehicles or systems and external vehicles, pedestrians, and the environment. Based on the analysis of autonomous driving functional architecture, this method defines four types of autonomous driving relationships: action, control, decision, and perception.

[0071] B. UML Activity Diagram Extension:

[0072] Figure 4 This refers to the UML activity diagram extension profile definition, with the following extensions: extending the CallBehaviorAction to describe three different levels of autonomous driving use cases; and extending the CallOperationAction to capture the system behavior of the autonomous driving system in four aspects: perception, planning, decision-making, and control. The specific implementation process is as follows:

[0073] The Autonomous Driving Constrained Use Case Modeling Language (RUCM4ADS) classifies autonomous driving use cases into control use cases, manipulation use cases, and strategy use cases based on the three-layer autonomous driving task described in the Wise Drive autonomous driving requirements framework. This method extends the CallBehaviorAction metamodel to capture different types of scenario use cases in the RUCM4ADS model: Control BehaviorAction, Manipulation BehaviorAction, and Strategy BehaviorAction. Each of these includes a relation attribute that records the calling relationships between use cases. The relation is an enumeration type, including two enumeration values: Include and Extend.

[0074] The UML activity diagram element `CallOperationAction` can be used to describe the behavior of use case actors. Referring to the autonomous driving function system architecture in the ISO 26262 functional safety standard and analyzing over 150 system activities in 46 autonomous driving scenario use cases described using the RUCM4ADS tool, this method extends `CallOperationAction` in three aspects: perception, planning, and control. Specific details of the extension are as follows:

[0075] 1) Perception Aspect: The perception aspect includes the perception of the main vehicle and the external environment (e.g., roads, traffic lights, road users). Therefore, a perception activity (CallPerceptionAction) is defined to describe the system's perception actions. This derivative is further divided into state perception activities (CallConditionDetectAction) and behavior perception activities (CallBehaviorDetectAction). State perception activities represent the system's perception actions regarding states, including the perception behavior of object states (e.g., the speed of the main vehicle or vehicles ahead, the color of traffic lights) and the relationship between the main vehicle and external objects (e.g., the distance between the main vehicle and vehicles ahead). Behavior perception activities describe the perception actions of object movement or intention, such as changing lanes, crossing the road, overtaking, etc.

[0076] 2) Planning Aspect: In the autonomous driving functional system, system planning and decision-making determine the behavior of autonomous vehicles, such as planning the globally optimal path, determining the target road, and deciding on overtaking. Therefore, derived planning activities (CallPlanAction) and decision-making activities (CallDecisionAction) are defined. Planning activities are further divided into task planning activities (CallMissonPlanAction) and motion planning activities (CallMotionPlanAction). Task planning activities describe a planned action, which is a comprehensive optimal plan from the current position to the target position. Motion planning activities describe the planned actions of vehicle motion behavior and trajectory. The impact of autonomous driving system decisions on the vehicle is reflected in changes in vehicle state and behavior. Therefore, decision-making activities (CallDecisionAction) are extended to state decision-making activities (CallVariableDecisionAction) and behavior decision-making activities (CallBehaviorDecisionAction). These two derived classes include variable and behavior attributes to capture the state values ​​and behaviors of system decisions.

[0077] 3) Control Aspect: In the architecture of an autonomous driving system, control generally refers to the system's control over the vehicle's trajectory (such as longitudinal and lateral control). This control over the vehicle ultimately manifests as the control of the vehicle's equipment. Therefore, we define a derived control activity (CallControlAction), which is further extended to behavior control activities (CallBehaviorControlAction) and actuator control activities (CallActuatorControlAction). Behavior control activities focus on representing the autonomous driving system's control behaviors in maintaining or completing a certain task. These control behaviors are strategic (e.g., the system controls the vehicle to return to its original lane) or directly reflected in the vehicle's trajectory (e.g., the system controls the vehicle to turn left). Specific behaviors are recorded using the Behavior attribute. The actuator control activity is used to capture the control operations of the system on the vehicle actuators (such as motors, lights, brakes, and steering). For example, the system controls the target vehicle to turn on the turn signals. It includes two attributes, actuator and action, which record the actuator and the control activity. The actuator is an enumeration attribute that includes enumeration values ​​such as engine (Motor), brake (Brake), and light (Light).

[0078] 2. The model conversion engine is the core of the model conversion method, used to convert RUCM4ADS models into UML extended models. Figure 2 The execution flowchart of this method includes:

[0079] Step 1: Use the RUCM4ADS modeling tool to build a requirement model for autonomous driving scenarios;

[0080] Step 2: Figure 5 This is a schematic diagram of the RUCM4ADS model parsing method described in this paper. The RUCM4ADS model template parsing process includes two steps. The first step is to identify the Actors related to the autonomous driving environment added in the RUCM4ADS use case template, including Road, Natural Environment, and Vehicle. The second step is to parse the event flow defined in the use case template, including the basic event flow, alternative event flow, and global event flow.

[0081] The event flow elements of the RUCM4ADS use case template consist of a set of requirement statements described in natural language. These statements include simple sentences, complex sentences, and special sentences. The processing of complex (identifying keywords, such as validate) sentences and special (identifying keywords, such as RESUME) sentences ultimately manifests as the processing of simple natural language representation sentences. For each simple sentence, this method uses a natural language parser (Stanford parser) to perform word segmentation, lexical tagging, and dependency parsing. Word segmentation yields each word, and part-of-speech tagging (POS) identifies the part of speech of each word, such as verb, adjective, noun, pronoun, preposition, etc. Dependency parsing is used to obtain the dependency relationships between words in the sentence (e.g., the dependency between subject and predicate), determining the sentence structure, including subject, predicate, object, and complement. The sentence structure further identifies the sentence type (Sentence Patterns). The intermediate model UCM4ADS defines multiple sentence types, including subject-verb (SV), subject-verb-object (SVDO), and subject-verb-object-complement (SVDOC). Finally, the semantic structure of the sentence is identified based on the meaning of the subject and object, such as receiving information, validation, and internal transaction. Finally, an intermediate model instance (UCM4ADS) is generated based on the parsed data.

[0082] Step 3: Apply model transformation rules to transform the intermediate model to obtain the target UML extended model. Model transformation rules are divided into two categories: transformation rules for class diagrams and activity diagrams. The specific rule definitions are as follows:

[0083] Class diagram rules are divided into two categories. The first category identifies class entities from possessive or non-possessive noun phrases (NPs). It identifies class instance attributes, operations, and different types of associations by analyzing the description strings preceding or following the noun phrases. The meta-model `SimpleSentence` records information after natural language parsing. `SimpleSentence` includes a `Subject` field, a `Predicate` field, and some modifier fields. `Subject` records the subject of the sentence and includes a core interface `NounFunctionForm`, which has many implementation classes (e.g., noun phrases, infinitive phrases, gerund phrases). The noun phrase structure defines `Pre-Head`, `Head`, and `Post-Head`. The `Head` field records noun information, while the `Pre-Head` and `Post-Head` fields record the modifier information before and after the noun. The second category, based on the first category's identification, applies transformation rules to generate class entity attributes, operations, and associations according to different sentence types (e.g., SVDO, SVIODO, SFDOC, etc.). Table 1 shows the UML class diagram transformation rule table a, and Table 2 shows the UML class diagram transformation rule table b.

[0084] Table 1

[0085]

[0086]

[0087] Table 2

[0088]

[0089]

[0090] Activity diagram rules are used to convert intermediate models into UML extended activity diagrams. Table 3 is a table of conversion rules from intermediate models to activity diagram extended models, including 19 specific rules, mainly categorized as follows:

[0091] Rule c1: Generate an activity graph for each autonomous driving scenario use case;

[0092] Rule c2: Generate a Constraint instance for the preconditions and postconditions in the autonomous driving scenario use case, and add the instance to the initial node or the terminating node of the activity graph.

[0093] Rule c3: Apply mapping rules to process simple, complex, and special sentences in the event stream;

[0094] Rule c4: Generate an instance of AcceptEvent and InterruptedActivityRegion for each global event stream, and apply rule c3 to process the sentences in the event stream;

[0095] Rule c5: Based on the sentence semantic structure obtained during the model parsing phase, clarify the system data flow interaction type and generate an input pin or output pin for each CallOperationAction; the data flow interaction types include: the system receiving data or information, the system verifying a request or data, and the system modifying internal values; Table 3

[0096]

[0097]

[0098] In its specific implementation, this application provides a computer storage medium and a corresponding data processing unit. The computer storage medium is capable of storing a computer program, which, when executed by the data processing unit, can run the invention's content regarding a modeling and model conversion method for autonomous driving requirements analysis, as well as some or all of the steps in various embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0099] Those skilled in the art will clearly understand that the technical solutions in the embodiments of the present invention can be implemented using computer programs and their corresponding general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of computer programs, i.e., software products. These computer program software products can be stored in a storage medium and include several instructions to cause a device containing a data processing unit (which may be a personal computer, server, microcontroller, MUU, or network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of the present invention.

[0100] This invention provides a modeling and model conversion method for autonomous driving requirements analysis. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment of the invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A modeling and model conversion method for autonomous driving requirements analysis, characterized in that, Includes the following steps: Step 1: Based on the Wise Drive autonomous driving requirements standard and autonomous driving system functional architecture, define the UML extended metamodel; the UML extended metamodel is used to construct the autonomous driving requirements model and to capture autonomous driving scenario elements in the source model RUCM4ADS during the model transformation process; Step 2: Import the autonomous driving scenario model RUCM4ADS, and parse the autonomous driving scenario model RUCM4ADS to obtain the intermediate model UCM4ADS. UCM4ADS defines a series of meta-models to record the information obtained from parsing. Step 3: Apply customized model transformation rules to the intermediate model to generate the target UML extended model. The customized model transformation rules include transformation rules for generating class diagrams and activity diagrams. Step 1 includes: referencing the Wise Drive standard and the functional architecture of autonomous driving systems, abstracting a domain conceptual model, and combining the domain concepts with the UML metamodel to extend the UML model: based on the lightweight extension mechanism of UML, extending the UML class diagram and activity diagram for the autonomous driving domain; in terms of the class diagram, defining ADSActor and specific participants to describe individuals in the autonomous driving scenario, defining Condition to describe the vehicle and environmental states in the autonomous driving scenario, and refining and extending the UML metamodel element Association; in terms of the activity diagram, extending CallBehaviorAction to describe three different levels of autonomous driving use case activities, and extending CallOperationAction to enable it to capture the system behavior of the autonomous driving system in four aspects: perception, planning, decision-making, and control; In step 2, the autonomous driving scenario model RUCM4ADS includes scenario participants and autonomous driving scenario use cases. The autonomous driving scenario use cases are used to describe all the behavioral activities of the system vehicle to complete a certain scenario task. Its core is the use case template UCSTemplate, which includes participants and event flow. The intermediate model UCM4ADS is used to store the information obtained from model parsing and defines the following meta-models: SentenceStructure, SentencePatterns, and SentenceSemantic. Step 2 specifically includes: Step 2-1, parsing the RUCM4ADS model elements, specifically includes the following steps: Step 2-1-1: Analyze the Actor concept elements in the RUCM4ADS model; Step 2-1-2: Analyze the autonomous driving scenario use cases (ADS Use Cases) contained in the RUCM4ADS model; Step 2-2: Initialize the intermediate model instance UCM4ADS based on the scene actors and event stream statements identified in Step 2-1, and the sentence types and semantic structures parsed from the natural language. In step 3, the conversion rules for generating class diagrams are used to convert the intermediate model into a UML extended class diagram, including: Rule b1: Identify class entities from possessive or non-possessive noun phrases (NPs); Rule b2: Identify class entity attributes, operations, and relationships between class entities by analyzing description strings with noun phrases before or after them; Rule b3: Based on the sentence type, apply mapping rules to generate the attributes, operations, and associations between corresponding class entities; In step 3, the conversion rules for generating the activity diagram are used to convert the intermediate model into a UML extended activity diagram, specifically including: Rule c1: Generate a UML activity diagram for each autonomous driving scenario use case in the RUCM4ADS model; Rule c2: For the precondition and postcondition in the autonomous driving scenario use case, form an instance of a constraint, and add the instance to the initial node or the terminating node of the activity graph. Rule c3: Apply mapping rules to process simple, complex, and special sentences in the event flow of the RUCM4ADS use case model; Rule c4: Generate an instance of AcceptEvent and InterruptbieActivityRegion for each global event candidate stream, and apply rule c3 to process sentences in the event stream; Rule c5: Based on the SentenceSemantic structure obtained during the model parsing phase, clarify the system data flow interaction type and generate an input Pin or output Pin for each CallOperationAction; the system data flow interaction types include: the system accepts data or information, the system verifies a request or data, and the system modifies internal values.

2. The method according to claim 1, characterized in that, In step 1, defining ADSActor and specific actors in the class diagram to describe individuals in the autonomous driving scenario specifically includes: According to the Wise Drive standard, the driving environment ontology is defined, including the metaclass ADSActor and specific environmental participants, namely the natural environment, roads, animals, human participants, and entities, where: The natural environment refers to the natural environment portion of the driving environment, including weather, temperature, and visibility; The road refers to the road conditions under autonomous driving scenarios, including road structure and surface conditions; The animals mentioned refer to animals in the scenario that may affect vehicle driving behavior, including attributes such as animal species and size. The human participants are divided into vehicle users and road users according to different usage types; based on the diversity of road participants in the scenario, road users are further divided into pedestrians, traffic controllers and animal riders. The term "entity" refers to entities other than humans in the context of autonomous driving.

3. The method according to claim 2, characterized in that, In step 1, the defined Condition describes the vehicle and environmental state in the autonomous driving scenario, specifically including: In the autonomous driving environment, in addition to the multiple participants in the driving task under the autonomous driving scenario, there are also various vehicle or environmental conditions. The vehicle or environmental conditions are divided into two categories: one is the vehicle and the environmental attribute variables related to the driving vehicle, and the other is the dynamic behavioral state of the environmental participants. The derived state Condition is defined to describe the autonomous driving scenario status, specifically extended to vehicle or environmental activity status and vehicle-related attribute status. The vehicle or environmental activity status includes attributes that record specific activities, and the vehicle-related attribute status includes two attributes: name and value.

4. The method according to claim 3, characterized in that, Step 1, which involves refining and expanding the UML metamodel element Association, specifically includes: The UML metamodel element Association is used to represent the relationship between classes. In the context of autonomous driving, it represents the relationship between autonomous vehicles or systems and external vehicles, pedestrians, and the environment. Based on the analysis of autonomous driving functional architecture, four types of autonomous driving relationships are defined: control, decision-making, perception, and general behavior relationships.

5. The method according to claim 4, characterized in that, In step 1, the activity graph is extended to CallBehaviorAction to describe three different levels of autonomous driving use case activities, specifically including: The autonomous driving constrained use case modeling language RUCM4ADS divides autonomous driving use cases into control use cases, manipulation use cases, and policy use cases based on the three-layer autonomous driving task described in the Wise Drive autonomous driving requirements framework. On this basis, the CallBehaviorAction metamodel is extended to three activities to capture scenario use cases at different levels in the RUCM4ADS model, namely control behavior activities, manipulation behavior activities, and policy behavior activities.

6. The method according to claim 5, characterized in that, In step 1, the CallOperationAction is extended to capture the system behavior of the autonomous driving system in four aspects: perception, planning, decision-making, and control. Specifically, this includes: The UML metamodel CallOperationAction is used to describe the behavior of use case actors. Referring to the autonomous driving tasks described in Wire Drive and the autonomous driving function system architecture in the ISO26262 functional safety standard, and analyzing the system activities in the autonomous driving scenario use cases described by the RUCM4ADS tool, CallOperationAction is extended from three aspects: perception, planning and control. Perception includes the perception of the main vehicle and the external environment. Derivative perception activities, such as CallPerceptionAction, are defined to describe the system's perception actions. These activities are further extended into state perception activities, such as CallConditionDetectAction and behavior perception activities, such as CallBehaviorDetectAction. State perception activities are used to represent the system's perception of state, while behavior perception activities describe the perception actions of the object's movement or intention. In terms of planning, this refers to the planning and decision-making made by the system based on perceived data. Based on the analysis of the autonomous driving system behavior in the ADS scenario modeled by RUCM4ADS, planning activities (CallPlanAction) and decision-making activities (CallDecisionAction) are defined. The planning activity (CallPlanAction) is further divided into task planning activities (CallMissonPlanAction) and motion planning activities (CallMotionPlanAction). Task planning activities describe a planned action, which is the comprehensive optimal plan from the current position to the target position; motion planning activities describe the planned actions of vehicle motion behavior and trajectory. Since the autonomous driving system's decisions affect the vehicle, reflected in changes in vehicle state and behavior, the decision-making activities are further extended to state decision activities (CallVariableDecisionAction) and behavior decision activities (CallBehaviorDecisionAction). In the architecture of an autonomous driving system, control refers to the low-level trajectory control of the main vehicle and the control activities directly performed on the vehicle's equipment. Therefore, a derivative control activity, CallControlAction, is defined. The derivative control activity, CallControlAction, is further divided into behavior control activity, CallBehaviorControlAction, and vehicle actuator control activity, CallActuatorControlAction. Behavior control activity is used to represent the control behavior of the autonomous driving system in controlling the main vehicle to maintain or complete the driving task, while vehicle actuator control activity is used to capture the control operations of the system operating the vehicle actuators.

7. The method according to claim 6, characterized in that, Step 2-1-2 specifically includes the following steps: Step 2-1-2-1: Obtain the actors included in each scenario use case, including elements such as road users, vehicles, and the natural environment; Step 2-1-2-2: Process the three event flows within the scenario use cases. Each event flow includes an event list and a post-condition. The event list is a collection of events, and each event is represented by a meta-model Sentence, representing a participant's action. Sentences have different generics, including SimpleSentence, ComplexSentence, and SpecialSentence. Simple sentences refer to statements described in natural language, complex sentences refer to statements including Condition, Iterator, Meanwhile, and Validate, and special sentences specify the relationships between events in use cases. For example, ResumeSentence contains the keyword RESUME STEP n, used to jump from the current event flow to the nth step of the basic event flow. The processing of the event flow involves processing the three different event statements. The specific parsing process includes the following steps: Step 2-1-2-2-1: If the statement is a special statement, identify the keywords to determine the specific statement type, and then determine the event flow step or other scenario use cases; Step 2-1-2-2-2: If the statement is complex, identify keywords to determine the statement type, then extract the simple statements inside, and proceed to step 2-1-2-2-3 for processing; Step 2-1-2-2-3: If the sentence type is a simple sentence, use the natural language processing technology Standard Parser for processing, including word segmentation, part-of-speech tagging, and dependency parsing. During this process, determine the sentence structure, including subject, predicate, object, and complement. Further identify the sentence type (Sentence Patterns) based on the sentence structure. The intermediate model UCM4ADS defines multiple sentence types, including subject-predicate SV, subject-predicate-object SVDO, and subject-predicate-object-complement SVDOC. Finally, identify the semantic structure of the sentence based on the meaning of the subject and object.

Images