An operating system suitable for cockpit domain controller

Abstract

The present invention relates to an operating system suitable for a cockpit domain controller, comprising: physical chip hardware, body software, and an OS system platform for connecting the physical chip hardware and the body software, wherein the OS system platform comprises: a GCC environment detection module, a middleware component module, a progress analysis module, and a granularity analysis module, wherein the GCC environment module is used as a compiler of the OS system platform to optimize multi-core codes, the middleware component module is used to shield the differences between different systems, the progress analysis module is used to perform code analysis and timing analysis of the OS system platform, and the granularity analysis module is used for thread monitoring in the OS system platform; the advantages of the present invention are: functional safety, functional diagnosis, body control, data monitoring, hierarchical thread monitoring, and multi-core control. After connecting the physical chip hardware and the body software, the high licensing fee of AUTOSAR OS in the actual automotive industry is solved in a relatively low-cost manner.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile domain controllers, and in particular to an AUTOSAR CPAP FREERTOS flexible platform operating system suitable for a cockpit domain controller. Background Art

[0002] Existing embedded systems include embOS, uc / OS-II / III, MicriumOS Kernel, FreeRTOS, Writtenstein SafeRTOS, OpenVX, Wind River Vxworks, Arccore-OS, ETAS-OS, Mentor-OS, and Vector-OS. Commonly used MCUs include: Infineon TC1797 / TC277 Freescale / NXP Mpc5xx / S12X. FreeRTOS is the most widely used real-time operating system in the industry (such as Telechips / Corechip), because the system is free, and the verified chip BSP resources are rich, and it can meet the real-time requirements of us microseconds. In particular, existing SOCs will reserve 1 or 2 security cores ARM R5 / R7, which are powerful and generally have a main frequency of more than 600Mhz, which is enough to meet the needs of vehicle body CAN interaction processing. The licensing fee for existing Autosar systems such as Vector-OS is staggering. Many low-cost automotive components cannot be used due to cost issues. Even Visteon, an international mainstream Tier 1, has developed its own uSar to save costs.

[0003] Domestic national brands urgently need their own body safety OS Trace function Autosar FreeRtos system, which follows the R20-11 specification, has a tool chain similar to Artop technology, cross-core distribution technology BSW Distribution for basic software, and meets ISO26262 hierarchical monitoring and information virtual safety test components. At the same time, a bus analysis interface is reserved to meet the CAN diagnosis, calibration, automated testing, and LAN test interfaces.

[0004] At present, the main pain points of B AutoSAR users on the market are as follows: 1. AutoSAR is designed for single-core users in order to meet the high-reliability timing requirements of automobiles. Currently, multi-core automotive processors have gradually become mainstream, but the performance has not been significantly improved. The reason is that a large part of the code cannot be parallelized, such as Figure 12. The interrupt mechanism ISR Category of AutoSAR is questioned by many people because the interrupt priority mechanism is full of randomness. Many precise timing operations, such as IO analog sensor (such as temperature, humidity and oxygen) bus communication, will be interrupted by a high-latency interrupt, which will cause timing confusion. However, completely disabling interrupts will cause the system to lose response in a certain time slice, and ultimately lead to the inability to guarantee the timing of some communications, such as Lin Slave communication. Figure 2 3. AUTOSAR multi-core OS designs a spin lock mechanism to achieve mutual exclusion of resources between cores and ensure data consistency. This mechanism is suitable for mutual exclusion of resources between cores and usually adopts the Shared Resource mechanism. Once the task nested request occupies the spin lock, it may cause the tasks to be locked together, such as Figure 3 shown. Summary of the invention

[0005] In view of the above problems, the purpose of the present invention is to provide an operating system suitable for a cockpit domain controller for functional safety, functional diagnosis, body control, data monitoring, hierarchical thread monitoring, and multi-core control. The system will connect the physical chip hardware and body software to solve the high licensing fees of AUTOSAR OS in the actual automotive industry at a lower cost, so as to overcome the shortcomings of the above-mentioned prior art.

[0006] The flexible platform operating system suitable for a cockpit domain controller provided by the present invention includes: physical chip hardware and body software. The improvement made is that it also includes an OS system platform for connecting the physical chip hardware and the body software. The OS system platform includes: a GCC environment detection module, a middleware component module, a progress analysis module and a granularity analysis module. The GCC environment detection module is used as a compiler of the OS system platform to optimize multi-core code, the middleware component module is used to shield differences between different systems, the progress analysis module is used to perform code analysis and timing analysis of the OS system platform, and the granularity analysis module is used for thread monitoring in the OS system platform.

[0007] As a preferred structure of the present invention, the middleware component module includes: identifying the initial waiting time, core execution time, total execution time, response time, deadline, difference time and cycle time of tasks A and B.

[0008] As a preferred structure of the present invention, the progress analysis module includes: a code analysis module and a timing analysis module, the code analysis module includes a static analysis module and a traceback measurement module, the static analysis module of the progress analysis module is used to analyze the space complexity of the program in the OS system platform in real time, and the traceback measurement module is used to interact with the coupling relationship between multiple CPUs of the OS system platform; the timing analysis module includes a static analysis module and a timing simulation module, the static analysis module of the timing analysis module is used to analyze the time complexity of the program in the OS system platform, and the timing simulation module is used to simulate and analyze the hardware characteristic parameters of the OS system platform.

[0009] As a preferred structure of the present invention, the granularity analysis module performs thread monitoring from the smallest granularity (lowest level) to the largest granularity (highest level) through the lowest hardware to the highest software, and the granularity analysis module performs thread monitoring on the Arm opcode layer, machine instruction layer, basic block layer, function library layer, executable status layer, task interrupt layer, ECU layer, network layer, and data bus of the OS system platform, wherein the actual controllable range is the basic block layer, function library layer, executable status layer, task interrupt layer, and ECU layer in sequence, the Arm opcode layer and machine instruction layer are located before the basic block layer, and the network layer and data bus layer are located after the ECU layer.

[0010] As the preferred structure of the present invention, the standard components EcuM, WdgM, Wdglf, Com, PduR, Dem, FIM, and Crypto-Stack Driver components of the OS system platform support cloned memory and concurrent resource exclusive access, secure memory isolation, and dual-core load balancing.

[0011] As a preferred structure of the present invention, the OS system platform also includes a tool chain module, a basic software cross-core allocation module, a layered monitoring, an information virtual security test module, a bus analysis port and a LAN test port.

[0012] The advantages and positive effects of the present invention are:

[0013] 1. The flexible platform operating system of the present invention has the advantages of functional safety, functional diagnosis, body control, data monitoring, layered thread monitoring, and multi-core control. After connecting the physical chip hardware and body software, it can solve the high licensing fee of AUTOSAR OS in the actual automotive industry in a low-cost manner.

[0014] 2. The present invention optimizes the multi-core code of the multi-core automotive processor through the GCC environment detection module, shields the differences between different systems through the middleware component module, solves the problem that completely shutting down interrupts will cause the system to lose response in a certain time slice, and ultimately leads to the inability to guarantee certain communication timings such as Lin Slave communication, and the mutual exclusion of resources between cores. The threads in the OS system platform are effectively analyzed and monitored through the progress analysis module. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] By referring to the following description in conjunction with the accompanying drawings, and with a more comprehensive understanding of the present invention, other objects and results of the present invention will become more apparent and easy to understand. In the accompanying drawings:

[0016] Figure 1 It is a schematic diagram of the prior art.

[0017] Figure 2 It is a schematic diagram of the prior art.

[0018] Figure 3 It is a schematic diagram of the prior art.

[0019] Figure 4 Schematic diagram of the progress analysis module according to an embodiment of the present invention.

[0020] Figure 5 Schematic diagram of the particle size analysis module according to an embodiment of the present invention.

[0021] Figure 6 Schematic diagram of the middleware component module according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] In the following description, for the purpose of illustration, in order to provide a comprehensive understanding of one or more embodiments, many specific details are set forth. However, it is apparent that these embodiments may also be implemented without these specific details. In other examples, for ease of describing one or more embodiments, known structures and devices are shown in the form of block diagrams.

[0023] Figure 1-6 A schematic diagram of the overall structure according to an embodiment of the present invention is shown.

[0024] like Figure 1-6As shown, the flexible platform operating system suitable for the cockpit domain controller provided by the embodiment of the present invention includes: physical chip hardware, body software, and an OS system platform for connecting the physical chip hardware and the body software, the OS system platform includes: a GCC environment detection module, a middleware component module, a progress analysis module and a granularity analysis module, wherein the GCC environment detection module is used as a compiler of the OS system platform to optimize multi-core code, the middleware component module is used to shield the differences between different systems, the progress analysis module is used to perform code analysis and timing analysis of the OS system platform, and the granularity analysis module is used for thread monitoring in the OS system platform.

[0025] The overall middleware component module of this embodiment includes: identifying the initial waiting time, core execution time, total execution time, response time, deadline time, difference time and cycle time of tasks A and B.

[0026] The overall progress analysis module of this embodiment includes: a code analysis module and a timing analysis module. The code analysis module includes a static analysis module and a tracing measurement module. The static analysis module of the progress analysis module is used to analyze the space complexity of the program in the OS system platform in real time, and the tracing measurement module is used to interact with the coupling relationship between multiple CPUs of the OS system platform; the timing analysis module includes a static analysis module and a timing simulation module. The static analysis module of the timing analysis module is used to analyze the time complexity of the program in the OS system platform, and the timing simulation module is used to simulate and analyze the hardware characteristic parameters of the OS system platform.

[0027] The overall granularity analysis module of this embodiment performs thread monitoring from the smallest granularity (lowest level) to the largest granularity (highest level) through the lowest hardware to the highest software. The granularity analysis module performs thread monitoring on the Arm opcode layer, machine instruction layer, basic block layer, function library layer, executable status layer, task interrupt layer, ECU layer, network layer, and data bus of the OS system platform, wherein the actual controllable range is the basic block layer, function library layer, executable status layer, task interrupt layer, and ECU layer, respectively; the Arm opcode layer and machine instruction layer are located before the basic block layer, and the network layer and data bus layer are located after the ECU layer.

[0028] The standard components of the overall OS system platform of this embodiment, EcuM, WdgM, Wdglf, Com, PduR, Dem, FIM, and Crypto-Stack Driver components, support cloned memory and concurrent resource exclusive access, secure memory isolation, and dual-core load balancing.

[0029] The overall OS system platform of this embodiment also includes a tool chain module, a basic software cross-core allocation module, a layered monitoring, an information virtual security test module, a bus analysis port and a LAN test port.

[0030] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. An operating system suitable for a cockpit domain controller, comprising: physical chip hardware and body software, characterized in that: Also included is an OS system platform for connecting physical chip hardware and vehicle body software, the OS system platform comprising: a GCC environment detection module, a middleware component module, a progress analysis module and a granularity analysis module, wherein the GCC environment detection module is used as a compiler of the OS system platform to optimize multi-core code, the middleware component module is used to shield differences between different systems, the progress analysis module is used to perform code analysis and timing analysis of the OS system platform, and the granularity analysis module is used for thread monitoring in the OS system platform; The middleware component module includes: identifying the initial waiting time, core execution time, total execution time, response time, deadline time, difference time and cycle time of tasks A and B; The progress analysis module includes: a code analysis module and a timing analysis module. The code analysis module includes a static analysis module and a traceback measurement module. The static analysis module of the progress analysis module is used to analyze the space complexity of the program in the OS system platform in real time, and the traceback measurement module is used to interact with the coupling relationship between multiple CPUs of the OS system platform. The timing analysis module includes a static analysis module and a timing simulation module. The static analysis module of the timing analysis module is used to analyze the time complexity of the program in the OS system platform, and the timing simulation module is used to simulate and analyze the hardware characteristic parameters of the OS system platform. The granularity analysis module performs thread monitoring from the smallest granularity to the largest granularity through the lowest hardware to the highest software. The granularity analysis module performs thread monitoring on the Arm opcode layer, machine instruction layer, basic block layer, function library layer, executable status layer, task interrupt layer, ECU layer, network layer, and data bus of the OS system platform, wherein the actual controllable range is the basic block layer, function library layer, executable status layer, task interrupt layer, and ECU layer in sequence, the Arm opcode layer and machine instruction layer are located before the basic block layer, and the network layer and data bus layer are located after the ECU layer.

2. The operating system applicable to a cockpit domain controller according to claim 1, characterized in that: The standard components of the OS system platform, EcuM, WdgM, Wdglf, Com, PduR, Dem, FIM, and Crypto-Stack Driver components, support cloned memory and concurrent resource exclusive access, secure memory isolation, and dual-core load balancing.

3. The operating system applicable to a cockpit domain controller according to claim 1, characterized in that: The OS system platform also includes a tool chain module, a basic software cross-core allocation module, a layered monitoring, an information virtual security test module, a bus analysis port and a LAN test port.

Images