RS20180001A1 - The procedure for configuring the autonomous vehicle in-vehicle system - Google Patents

Description

The process of configuring an autonomous driving system in a vehicle

Field of technology to which the invention relates

The invention belongs to the field of automotive industry and computer communication. More precisely, the invention relates to a technique for determining the risk level of individual applications in an automotive computer system. According to the international patent classification, the invention is designated by the basic classification symbol G06F9/44552, G06F21/62, G06F12/14, G06F9/50.

Purpose of the invention

To help solve the problem of the diversity of core architectures in ADAS platforms, Middleware-y needs the help of a platform development kit that manages multi-core architectures. Such a development kit must be able to integrate heterogeneous execution of concurrent tasks and remove the burden of managing data transfers or clear copies of data between processes.

The aim of the invention is to achieve a risk level that is tolerable for autonomous car systems in order to ensure safe driving conditions. More specifically, the aim of the invention is to reduce system errors when executing applications by applying a different process design method and to assign a certain required level of safety to each element of the system.

State of the art

The existing state of the art includes the following inventions that differ in their functionality from the presented invention.

Patent application EP2907072 (B1) published on 19.08.2015 under the title "Method for controlling separated running of linked program blocks and control device” proposes an application relating to a method for controlling a separate sequence of linked program blocks designed to implement functions of safety-relevant systems, in particular in motor vehicles. Specifically, program blocks are formed to implement functions of the motor vehicle drive or other vehicle-specific applications, such as steering systems or vehicle or passenger safety systems.

Patent application US20150212952A1 published on 30.07.2015. entitled "Method for the coexistence of software having different safety levels in a multicore processor system" proposes a method for the coexistence of software with different security levels in a multiprocessor that has at least two processor cores. A memory area is associated with each processor core and the software is processed on one processor core that has a predefined security level. Processing of software with a predefined security level is performed only on a processor core with the same security level, in which when processing the software, the processor core only accesses a protected memory area that is permanently associated with the processor core.

Patent application JR2015067107A published on 13.04.2015. under the title "Vehicle control device" proposes a method for providing vehicle control and ensuring safety, without additional data processing overhead, even if the operation of a large number of different applications is allowed in terms of safety standards. According to the subject invention, the software is specifically classified according to the classification in accordance with the operating mode and general safety integrity demarcation (ASIL, QM).

Exposition of the essence of the invention

The development of passenger cars has become one of the most demanding tasks with the increasing demands for vehicle control. The challenges that arise in order to achieve full self-driving passenger vehicles are being addressed by using modern technologies such as artificial intelligence, machine learning and sensor technology. The use of these technologies also requires the use of new technology for the verification and validation of software components before production begins. This is especially important for the exchange of safety-critical applications in the vehicle.

Safety aspects must be taken into account when developing a modern passenger vehicle. One of the facts that shows the level of complexity of these systems is their fragmentation in the sense that the system is composed of multiple functional parts and subsystems. In order to properly perform verification and validation, the development of hardware and software must be done according to the specified standard ISO 26262. This standard defines an approach based on determining the risk level of individual applications, specific to passenger vehicles, in order to achieve the necessary risk reduction and achieve an acceptable risk, which is called the Automotive Safety Integrity Level (ASIL). The functional safety prescribed by this standard implies the safety of the electronic systems in a passenger car. The possible ASIL levels are QM, ASIL A, ASIL B, ASIL C and ASIL D. ASIL D requires the highest level of risk reduction, while for QM a nominal quality measure applied in the automotive industry is sufficient. With the application of the V model in the ISO 26262 standard, the first step of the engineering requirements is to perform a hazard analysis and risk assessment for the system under consideration. The output of this step is given according to the safety objectives described by the highest level of safety requirements. The concept of functional safety is divided into functional safety requirements in order to achieve the safety objectives of the hazard analysis. The determination of the functional safety of an electronic system takes place in several phases. The goal of each phase is to develop such a software architecture that will pass validation and verification testing.

What is proposed by this solution is to gradually raise the system safety level from the QM level to the ASIL D level. In order to achieve the functional safety goals, hardware and software must be seamlessly integrated to ensure full coverage of safety requirements. By integrating functional safety into the passenger vehicle electronics system and including potential software that will run on these components, guidelines are given for the functioning of individual hardware components by specifying requirements for the entire product life cycle. Safety goals are defined by developing applications and assigning a specific ASIL safety level to each operation. This scalable approach ensures simplification of system design and reduction of software complexity. More precisely, implementing such an architecture allows for a reduction in the number of system components, functional safety requirements are addressed, and reliability is increased. Applications that benefit from this approach include power steering, electronic stability control, frame (chassis) control, safety control, adaptive cruise control, and blind spot detection.

The need for standardization arose with the emergence of the need for software-based vehicle management. Autonomous driving will change the lifestyle of society, reduce traffic accidents, and increase the efficiency of passenger transport. The amount of data exchange within vehicles and between vehicles is also increasing, so the communication network must be adapted to ensure a known message exchange time in advance.

Brief description of the invention images

Figure 1a. QM security level architecture diagram.

Figure 2b. ASIL B safety level architecture diagram.

Figure Zc. ASIL D safety level architecture diagram.

Figure 2. Development method of the QM safety level architecture into the ASIL B safety level architecture.

Figure 3. Development method from ASIL B safety level architecture to ASIL D safety level architecture.

Detailed description of the invention

The possibility of implementing autonomous driving and in-vehicle infotainment systems on a single platform requires the use of an adaptive software stack (AUTOSAR Adaptive) that is intended for further customization according to needs and purpose and the implementation of certain modules according to strict safety standards in order to arrive at a solution that can be used as a software layer that can be integrated into various automotive platforms in the industry.

Figure 1a. shows the architecture of the QM security level. The architecture consists of a system-on-chip 100a, a communication subsystem 120a, and a sensor fusion subsystem 140a. The system-on-chip 100a consists of an input/output subsystem - cameras, a digital signal processor (DSP), a memory unit, a multi-core general-purpose processor, and a graphics processing unit. The software stack 110a at the QM security level consists of a general-purpose operating system (Linux or Android), a middle layer with an application lifecycle manager, hardware acceleration functions (graphics SDK - oren GL and oren CL and DSP SDK), a camera manager and a module for exchanging multimedia messages over the network, then a unified application interface and an application for the infotainment program, a multimedia system for passengers, a cluster display, a windshield display, a driver information algorithm, vehicle control algorithms, driver assistance algorithms with feedback. The communication subsystem 120a includes an input-output subsystem - Ethernet, a microcontroller, a memory unit, while the software stack of the communication subsystem 130a consists of an operating system kernel and router applications. The communication subsystem

The sensor fusion 140a consists of an input/output subsystem, automotive subsystems (CAN, LIN, Flexray), a microcontroller, and a memory unit. The software stack of the sensor fusion subsystem 150a has elements of a kernel operating system, CAN/ LIN/ Flexray/ Ethernet handlers, and applications for sending sensor data to the system.

Figure 16 shows the architecture of the ASIL V security level. The system on a chip 1006 remains the same. What is changed in order to increase the security level is the software stack 110b, i.e. modules have been added or changed compared to the architecture of the first lower ASIL level and applications that are adapted to the higher security level have been changed. The visualization module enables emulation of hardware resources and thus a virtual processor, graphics unit, memory and digital signal processor are obtained, all in order to be able to use two operating systems, a general-purpose operating system (Linux or Android) which is also present in the QM security level architecture and a new additional real-time operating system (e.g. QNH) for applications that require more reliable and faster execution. In order for the system to function at a higher level of security, that is, to achieve more efficient management of microcontrollers in the vehicle, it is necessary to expand the middle layer with the implementation of a shared graphics buffer handler, a messaging module and an application lifecycle handler. In this architecture, changes were also made to the applications of the passenger multimedia system, infotainment system, driver information assistance, cluster operation applications, windshield and vehicle management. The communication subsystem 120b with the software stack 130b in the ASIL V architecture remains the same as at the QM level, while the software stack 150b of the sensor fusion subsystem 140b at this security level changes compared to the previous one and now consists of a real-time operating system, an adaptation layer (AUTOSAR MCAL), an AUTOSAR middle layer, an RTE (Runtime Environment), a sensor fusion service, an application for sending sensor data to the system,

Figure 1c shows the ASIL D architecture. The system-on-chip 100c is unchanged from the previous architecture. To raise the security level to ASIL D, it is necessary to make a change in the software stack 110c by extending the middle layer of the Linux operating system by adding modules for hardware acceleration functions (DSP SDK and native graphics SDK). The middle layer of the real-time operating system is also extended by incorporating a module for deterministic task scheduling and a module for deterministic communication. The software stack 130c of the communication subsystem 120c is adapted

deterministic data exchange, so in addition to the operating system core, a deterministic communication handler, a deterministic communication configurator, and a Deterministic Ethernet router application are introduced. The sensor fusion subsystem 140c with the 150c software stack is unchanged from the ASIL V architecture. What is important to emphasize is that Deterministic Ethernet is used for communication in this architecture.

The algorithm in Figure 2 provides a development process for the QM security level architecture into the ASIL V system security level architecture. The process begins with the step of providing a hypervisor 210 for virtualization programs in order to better utilize hardware resources, which includes loading the hypervisor image into the system's program memory 211, then transferring the middle layer of the QM security level architecture 212, where a set of specifications describing the program modules and defining the application interface are implemented and the validation of applications 213 that imply the ASIL V security level architecture in the hypervisor environment in the Linux operating system is performed, where an assessment is made of whether the application complies with the requirements and whether it meets user needs and the appropriate level of security.

The middleware architecture modification includes the step of implementing a multimedia messaging module 220 that implements a graphical messaging interface with non-critical multimedia applications using an Ethernet interface 221 and implementing a graphical messaging interface with critical multimedia applications by writing the graphics into the shared memory of the hypervisor 222.

Step 230 provides a software stack for the real-time operating system where temporary security-critical data is formed and placed in the software stack 110b. This step includes translating the security middleware for the real-time operating system (QNX) 231, then providing a coupling for the functioning of hardware acceleration in the real-time operating system 233 and transferring the multimedia messaging module for the real-time operating system 234.

Step 240: Extending the messaging module 240 involves adding a branch: if the message is not graphic, the exchange is implemented using the Ethernet interface 241, adding a branch: if the message is not graphic, the message is processed using the multimedia messaging module interface 242, and porting the messaging module to a real-time operating system 243.

The step of providing the software stack of the sensor fusion system 250 includes providing a real-time operating system compatible with the AUTOSAR standard 251, implementing an adaptation layer for the target hardware platform of the sensor fusion system 252, porting the AUTOSAR layer 253, implementing the AUTOSAR layer service for supplying sensor messages from the CAN, LIN and FlexRay buses 254 and modifying the application for sending sensor data to the system, so that instead of CAN, LIN and FlexRay handlers, it uses the AUTOSAR service 255 for supplying data.

With the step of mapping the unified application interface for the application lifecycle manager 260, the security middleware for the Cpih 261 is first translated and then the mapping of the application lifecycle management functions to the unified application interface 262 is performed. This mapping of the lifecycle management functions 262 includes the mapping of the start/stop functions 263, the mapping of the pause/resume functions 264 and the mapping of the messaging and event functions 265. Further, within the step of mapping the unified application interface for the application lifecycle manager 260, the mapping of the communication functions to the messaging module functions 266 is performed and finally the process ends with the step of application validation 229, which checks the functionality of the applications for the ASIL V safety level architecture.

The algorithm in Figure 3 provides a development process from the ASIL V security level architecture to the ASIL D security level architecture. The process begins with a step of analyzing the network traffic of applications (initially K=1) 310, with which the application K 311 is launched. During operation, the used flow of the application K 312 is measured in order to determine whether the flow is greater than the previous maximum 313 and if not, it is checked whether the representative execution time has expired 314. In the event that the flow is greater than the previous maximum, the highest flow for the application K 315 is updated and then it is checked whether the representative execution time has expired 314. If the representative time has not expired, the process will be repeated from the measurement of the used flow of the application K 312, however, if the representative execution time has expired, it is checked whether all applications have been processed 316. The transition to the application K=K+1317 will occurs if it is determined that there are still unprocessed applications. When the transition to the next unprocessed application is made, the process is repeated from the start of the K application.

After processing all applications, step 320 is used to install a subsystem to support the deterministic network protocol. This involves connecting the subsystems via an Ethernet connection 321 and configuring the subsystems with the obtained maximum application flows (flow allocation) 322.

The step of expanding the middle layer of the real-time operating system 330 consists of installing a deterministic communications handler 331, configuring the deterministic communications handler based on the maximum application flows (flow allocation) 332, then coupling the deterministic communications handler with the messaging module 333 and installing a deterministic task scheduler 334. In order to properly install the deterministic task scheduler 334, a fixed quantum of execution time is assigned to all applications (initially K=1) 335 and then the validation of the application's operation for real time 336. If the query whether the real-time operation is satisfied 337 does not meet the condition, the process will proceed to increasing the application's execution time quantum K by a fixed increment 338 and then it will be checked whether the processor still has available time 339. In the event that there is none, application optimization 340 is performed where all applications must be optimized and the process continues with the allocation of a fixed quantum of execution time for all applications 335. If the check whether the processor still has available time 339 determines that it does, the process continues with the validation of the operation of the application K for real time 336. When the real-time operation is satisfied but if not all applications have been processed 341, the transition is made to the application K=K+1 342 and the process is then repeated from the validation of the operation of the application K for real time 336.

Once all applications have been processed, the process moves on to the step of extending the middle layer of the Linux operating system 350. The extension is reduced to adding a native graphics SDK 351 and aligning the native graphics SDK with the graphics interface of the unified application interface 352. The application validation step 360 checks the functionality of the applications for the ASIL D safety level, which completes the entire process.

Method of industrial and other application of the invention

The invention finds application in the automotive industry. The invention can be applied on any platform with multi-core architecture. The invention can be used when it is necessary to solve the problem of integrating functional safety into the electronics system of autonomous vehicles and including a potential software solution that will work on the given components. By gradually raising the system safety level from the QM level to the ASIL D level, the system design is simplified and the software complexity is reduced.

Claims (6)

Patent claims 1. The method of configuring an autonomous driving system in a vehicle enables configuring a program stack 110a of a system on a chip 100a, a program stack 130a of a communication subsystem 120a, and a program stack 150a of a sensor fusion subsystem 140a and configuring a program stack 110b of a system on a chip 100b, a program stack 130b of a communication subsystem 120b, and a program stack 150b of a sensor fusion subsystem 1406, characterized by that the change from the QM safety level architecture to the ASIL V safety level architecture begins with the step of providing a hypervisor (210) where the virtual division of the hardware resources of the system on a chip (100b) is performed, that the step of implementing a multimedia messaging module (220) into the software stack (110b) ensures the exchange of graphical content messages between critical and non-critical applications, that the step of providing a software stack for a real-time operating system (230) in the software stack (150b), where a real-time system of a higher level of security is introduced, that the step of extending the messaging module (240) in the software stack (110b), provides a mechanism for recognizing messages so that the processing of graphic messages is carried out by the multimedia messaging module interface while all other messages are processed by the Ethernet interface, that the step of extending the software stack of the sensor fusion system (250) of the sensor fusion subsystem (140b) introduces a real-time operating system compatible with the AUTOSAR standard and where an adaptation layer for the hardware platform is provided in order to achieve the exchange of sensor messages in the system, that the step of mapping a single application lifecycle handler interface (260) to the software stack (110b) performs functions for mapping the application lifecycle to a single application interface and mapping communication functions for modules, that the application validation step (270) verifies the functionality of applications for ASIL B safety level architecture, that the change from the ASIL B security level architecture to the ASIL D security level architecture begins with the step of analyzing the network traffic of all applications (310) analyzing the applications to ensure the required bandwidth, that the step of incorporating a subsystem for supporting a deterministic network protocol (320) into the software stack (130c) connects the system to the Ethernet network and allocates the required bandwidth, that the step of extending the middle layer of the real-time operating system (330) in the software stack (110c) provides a coupling between the handler and the applications with deterministic communication and ensures the execution of the applications in an allocated fixed time, that the Linux middleware extension step (350) in the software stack (110c) adds tools for unifying a single application interface, and that the application validation step (360) verifies the functionality of applications for the ASIL D safety level architecture. 2. The method defined in claim 1, characterized in that the autonomous driving algorithms are based on ultrasonic sensors, lidars and radars. 3. The method defined according to claim 1, characterized in that a CAN, LIN and Flexray bus is used to supply sensor messages. 4. The method defined in claim 1, characterized in that the modification of the ASIL V safety level architecture constitutes an iteration that uses a method for expansion with deterministic software blocks. 5. The method defined in claim 1, characterized in that a deterministic Ethernet is used to support the deterministic protocol. 6. The method defined according to claim 1, characterized in that the application is executed in certain time intervals on the ASIL B level architecture and the ASIL D level architecture.