Author: Yan know car
The process of intelligence includes intelligent networking, intelligent cabin, and autonomous driving. In this environment of intelligent driving, people’s demand for its products and innovation will be even stronger, but the current state is that the maturity and innovation of mass-produced features have not fully met people’s expectations. Coupled with the lack of mature/stable reference benchmarks, smart driving has a wider range of requirements for scenario design and feature development. The development of features itself requires more input from the scenario design, continuously turning the insight of each scenario into real user benefits.
The application of scenario design in system development
Based on the above understanding, the key to product innovation lies in two ends: one is the observation and prediction of seed users’ lifestyle/vehicle use methods, and the other is the deep combing of benchmark product function/technology/operation and experience trends.
“Scenario” is the key carrier of all thinking, and innovation without scenarios is difficult for cross-functional teams to understand real needs and to achieve consensus. Therefore, building an “executable scenario library” is a prerequisite for building intelligent driving functions and is critical to guiding subsequent product innovation work. The so-called “executable” means that the scenario library can correspond to accurate functional and experiential requirements. Different scenarios have comparability in the trade-off process.
Highly autonomous driving, as the core of intelligence, requires a relatively complete scenario library in its system design. Scenarios are a crucial part of autonomous driving system development and testing. The safety and quality of autonomous driving require that the autonomous driving test scenarios have characteristics such as diversity, coverage, and typicality, and that these characteristics can affect the accuracy of the test results.
Compared to traditional cars, autonomous driving cars have a significantly different evaluation system for testing and assessment content and form. The fundamental change lies in the fact that autonomous driving focuses more on evaluating the coordination of the entire vehicle’s multi-sensors and the perception, judgment, and decision-making ability output from sensor fusion. And the testing scenarios for autonomous driving cars require diversity and typicality and need to cover all complex special scenarios as much as possible; software and hardware devices for autonomous driving system development and testing have also undergone significant changes.# Designing Autonomous Driving Scenario Library from a Systems Development Perspective
This article focuses on designing an autonomous driving scenario library from a system development point of view, excluding discussions on the construction and impact of automated driving tests. The aim is to apply the analysis of autonomous driving scenarios and use cases during the design stage to enhance the user experience in all aspects, effectively improve the function lists, clearly express user requirements, and ultimately assist in system function design and testing verification. To achieve this process, it is necessary to integrate human-vehicle-environment scenarios in the design.
Building a Scenario Library in System Design
When autonomous vehicles are on the road, they face a wide range of complex environments. A single development process and testing system cannot possibly encompass all possible scenarios. Therefore, various testing scenarios can be classified following certain categories. Typical scenario construction includes two major units:
1. Scenario Elements
Some critical points in the scenario elements unit include scene objects, road conditions, environmental factors, and driving behaviors.
2. Test Scenario System Architecture
The scene system architecture can combine the various scenario elements in different categories to establish a complete scenario library. The following describes the basic construction process of a scenario library.
- Extract use cases based on scenarios (pain points)
The first step in building an executable scenario library is a comprehensive methodology for managing user experiences. In other words, it is necessary to identify “key elements” in the sequence, which serves the complete user experience and management system based on that scenario. The complete logic of the scenario library decides its architecture.
- Extract feature highlights based on use cases
The second step is to define the scenario correctly (according to the execution logic). The scene is a statement of a specific set of variables that corresponds to user intentions and is triggered by specific events.
Based on the definition of the scenario, a layered scene structure is required. Hierarchical division is a commonly used method for scene definitions, by breaking down the scene elements into different levels. In general, we divide the elements into three levels, as shown in the following diagram.
For example, we can break down a typical autonomous driving function scenario. Here, we design a scenario where a user needs to drive from point A to point B. During the journey, the user will pass through urban road sections, enter a toll station, drive on a ramp to a highway section, leave the toll station, drive on another ramp, and finally reach the destination.In the process of driving, different weather conditions, road environments, dynamic vehicle conditions, and driver usage conditions can be experienced. By decomposing and combining the above information, different road scenarios can be completely simulated. During the design process, we need to build initial strategies for these scenario environments separately.
For example, under the condition of backlight and normal weather conditions and when the vehicle enters a larger curved road with no interference from other vehicles, the driver is not in control of the vehicle and is somewhat distracted. How should the system control the vehicle? At this time, we can control the vehicle to decelerate normally and issue a certain level of alarm or notification to the driver.
Of course, the above is just one scenario example. In our actual design process, there are many other scenario combinations that cannot be enumerated manually in manual mode.
Therefore, we do not recommend manual combination building in the actual scenario construction process, but rather to use machine operation methods.
In fact, this method uses scene elements as input to achieve scene generalization. The generalized scene almost contains all the scenes under the combination of the scene elements. Of course, there may be unreasonable scene combinations, such as when the vehicle experiences significant acceleration, but the user is pressing the brake pedal to slow down.
Therefore, in the later stage of scene generalization, it is necessary to design a reasonable model to filter out unreasonable scene demands.
Based on the above analysis, we can comprehensively judge that the process of scenario construction needs to fully grasp the scenario itself, scenario elements or scenario factors, and scenario combination methods.
Regarding the definition of scenario demands, scenarios themselves cannot be exhaustively enumerated. However, in order to describe product positioning issues, scenarios need to be divided into two levels: the first-level scenario needs to be structured, and is jointly described by the most critical two dimensions (user and usage scenario), which determines product positioning. The second-level scenario refers to specific function development, which is jointly described by all dimensions that affect the functional goals.
The third step is to structuredly describe the scenarios and sort out the user demands for each scenario. Scenarios correspond to user intent (i.e. user tasks), and user tasks correspond to specific functions and solutions, so that the scenario library can be executed downwards.
In addition, the scenario library must be continuous, accumulative, open for collection and dynamic management, and fully connected to the main system. In the process of intelligence, product definition is still the dynamic balance between expected target users, usage scenarios, existing technical solutions, and new technologies/new solutions.
That is to say, we can abstract the product definition process as a dynamic matching process between target users, usage scenarios, function combinations, and innovative technologies. This abstraction makes data collection, processing, and tracking more standardized, making it possible to build a product definition system.
In order to solve the user experience problems of specific users and specific scenarios, we need to decompose specific user tasks within the primary scenario, combine the functions that solve these user tasks, and determine the specific configurations (solutions) that support these functions.
Functional development based on scenario definition and shadow data collection
For the design of autonomous driving systems, it is necessary to form a system development requirements specification based on product definition process, data specifications, and usage scenarios.
In the above system, functionality is a response to user intentions, it atomizes user intentions, and responds to user intentions, which is a zero-based thinking of user needs. In order to achieve functional subitems for vehicle models, configuration optimization needs to be performed in advance. The optimization process is the specific solution for selecting functional implementation.
In order to achieve effective functional development based on scenario definition (including process definition, designation of standard data, and definition of effective application scenarios), in the above system, the collection of requirements and ideas is a prerequisite for discovering new requirements and scenarios, and specific operations need to be decomposed into the following steps.
1. Requirement data collection
It can obtain more extensive data source information through desk studies, telephone interviews, WeChat mini-programs, Web, and other social methods as entry points.
Functional model construction:
According to the data source information, the original system functional model can be constructed. This functional model needs to be combined with user research, vehicle benchmarking data, etc., as input for requirements.
In addition, based on the aforementioned scenario building method, combining scene elements according to certain rules for effective scene combination, and finally defining suitable usage scenarios. Secondly, define the mapping relationship between system functions and data sources, which is defined based on the data formats and requirements of each data source. Then, according to the actual situation, determine the data processing method/algorithm, so that a simple functional model is built.
2. Structuring of requirement data
Provide a pre-established structured labeling system to enable data providers to automatically complete related work such as sorting and structuring when initially entering data.
Effective data integration:
The future development of intelligent driving is achieved by continuously collecting scene data in the early stage, integrating input models, and effectively cleaning up and standardizing/structuring data.
This process is actually to effectively integrate the existing data in the database and the updated data continuously collected to form corresponding structured data, thus ultimately ensuring the orderliness, completeness, and rationality of later functional development.
3. Data distribution and discussionAccording to the characteristics of the products under research, the structured data is distributed and discussed to explore the actual scenarios, experience factors, and feasible technical solutions.
Design based on original functions:
Original functions require the design of functional architecture for new scenes, new user tasks, user pain points, new ideas, experience factors and other aspects in the distributed data.
This process can be expanded through brainstorming in a discussion mode, and as many functions and functional data can be effectively analyzed and classified as possible. Finally, the optimal functions are selected and extracted for subsequent detailed development.
4. Application in product definition
Finally, by integrating with user groups, benchmark libraries, and creative libraries, the target user requirements in product definition are explored and managed.
Iterative optimization of adaptive system functions:
Developing effective system functions requires analysis and strategy design based on the integrated data. First, conduct data trial runs and algorithm iteration/optimization.
Secondly, define the algorithm and display strategy according to the business scenario requirements, including front-end interface design and back-end function design, and finally form a structured database. Supporting the development of system functions, function trial runs, function iteration optimization, and ultimately creating better user experience by updating product value.
Summary
Scenarios can be applied to the entire standard automated driving system development process to obtain suitable products, from the conceptual stage to product development, system validation, and testing. In the entire development cycle, it is required to have consistent description of the scenarios at different abstract levels.
Among them, mining test scenarios, enriching and improving test techniques are very important steps to improve the safety performance of automated driving.
Firstly, input and store scenario sources from three sources: roadside data, onboard data, and virtual data; secondly, build a hierarchical and planned scenario library through scenario mining, scenario classification, scenario deduction, and other methods; finally, apply the scenario library to the scenario testing process, including software in the loop, hardware in the loop, whole vehicle in the loop, closed roads, and open roads.
In system design, more attention needs to be paid to the safety, comfort, novelty and other issues brought by the above scenario construction.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.