WO2023125635A1 - 车载操作系统、调试系统及方法、电子设备及存储介质 - Google Patents

车载操作系统、调试系统及方法、电子设备及存储介质 Download PDF

Info

Publication number
WO2023125635A1
WO2023125635A1 PCT/CN2022/142712 CN2022142712W WO2023125635A1 WO 2023125635 A1 WO2023125635 A1 WO 2023125635A1 CN 2022142712 W CN2022142712 W CN 2022142712W WO 2023125635 A1 WO2023125635 A1 WO 2023125635A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
beos
vehicle
debugging
module
Prior art date
Application number
PCT/CN2022/142712
Other languages
English (en)
French (fr)
Inventor
周欢
罗锦文
Original Assignee
比亚迪股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 比亚迪股份有限公司 filed Critical 比亚迪股份有限公司
Priority to KR1020247006082A priority Critical patent/KR20240033083A/ko
Publication of WO2023125635A1 publication Critical patent/WO2023125635A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • the present disclosure generally relates to the field of vehicle technology, and in particular, relates to a vehicle operating system, a debugging system and method, electronic equipment, and a storage medium.
  • the frame design of the existing vehicle-mounted operating system is general and single, such as: a lot of vehicle-mounted software uses a single-chip microcomputer as a controller.
  • this development model has great disadvantages.
  • the maintainability of the code is poor, and second, the scalability of the program is poor.
  • the project is poor in portability. It is more and more important that some day in the future, the software that is currently free may not continue to be free, which indirectly increases the cost of use and the cost of car companies.
  • a vehicle-mounted operating system, a debugging system and method, electronic equipment, and a storage medium A vehicle-mounted operating system, a debugging system and method, electronic equipment, and a storage medium.
  • the self-developed embedded BEOS operating system is used to make the vehicle-mounted operating system provided by the embodiments of the present disclosure better in real-time, more stable, and more secure .
  • the corresponding BEOS debugging system is configured for the vehicle operating system, so that the vehicle software can be better developed, verified, debugged and maintained on the self-developed vehicle operating system.
  • the present disclosure proposes a vehicle-mounted operating system, including a hardware layer, a software layer, and an application layer arranged sequentially from bottom to top; wherein,
  • the hardware layer includes at least one controller hardware, each of the controller hardware includes a processor;
  • the software layer includes a BEOS operating system and a BEOS driver; wherein, the BEOS operating system is used to manage and control hardware and software resources of the computer system, and the BEOS driver is used to complete data transmission between the hardware layer and the software layer;
  • the application layer includes a plurality of application programs, which are connected to the BEOS operating system through an operating system interface, and each of the application programs is used to provide a vehicle-related application.
  • the vehicle-mounted operating system of the embodiment of the disclosure by utilizing the self-developed embedded BEOS operating system, the real-time performance and stability of the vehicle-mounted operating system provided by the embodiment of the disclosure are better, and the security is stronger.
  • the present disclosure proposes a BEOS debugging system, which runs on a PC and is used for developing, verifying, debugging, and maintaining a vehicle-mounted operating system.
  • the vehicle-mounted software can be better developed, verified, debugged, maintained, etc. on the self-developed vehicle-mounted operating system.
  • the vehicle-mounted software can be better developed, verified, debugged, maintained, etc. on the self-developed vehicle-mounted operating system.
  • the present disclosure proposes a BEOS debugging method, including:
  • the BEOS debugging system sends debugging instructions to the vehicle operating system
  • the on-board operating system debugs the object to be debugged according to the debugging instruction
  • the object to be debugged runs according to the debugging instruction, and feeds back the running result to the BEOS debugging system;
  • the BEOS debugging system determines the performance of the object to be debugged according to the running results of the object to be debugged.
  • the developer can check the logic of the program, the status of the window program, etc. through the BEOS debugging system and print them out to check and perform corresponding adjustment tests.
  • the present disclosure provides an electronic device, the electronic device includes a processor and a memory, at least one instruction, at least one program, code set or instruction set are stored in the memory, the instruction, the program , the code set or the instruction set is loaded and executed by the processor to implement the steps of the BEOS debugging method provided by various embodiments of the present disclosure, and the steps of the task synchronization, communication and driving methods in the vehicle operating system.
  • the present disclosure provides a computer-readable storage medium, where one or more programs are stored in the computer-readable storage medium, and the one or more programs can be executed by one or more processors to realize The steps of the BEOS debugging method provided by various embodiments of the present disclosure, and the steps of the task synchronization, communication and driving methods in the vehicle operating system.
  • FIG. 1 is an architecture diagram of a combination of a vehicle-mounted operating system and a BEOS debugging system provided by an embodiment of the present disclosure
  • FIG. 2 is a specific architecture diagram of the combination of the BEOS operating system provided by the embodiment of the present disclosure and the corresponding BEOS driver;
  • FIG. 3 is a structural diagram of a data persistence management module provided by an embodiment of the present disclosure.
  • FIG. 4 is a task framework diagram of an on-vehicle operating system provided by an embodiment of the present disclosure
  • FIG. 5 is a task synchronization diagram of a vehicle-mounted operating system provided by an embodiment of the present disclosure
  • FIG. 6 is a task communication diagram of a first implementation manner of a vehicle-mounted operating system provided by an embodiment of the present disclosure
  • FIG. 7 is a task communication diagram of a second implementation manner of a vehicle-mounted operating system provided by an embodiment of the present disclosure.
  • FIG. 8 is a BEOS driver diagram of a vehicle operating system provided by an embodiment of the present disclosure.
  • FIG. 9 is a CAN driving example diagram provided by an embodiment of the present disclosure.
  • FIG. 10 is a diagram of a BEOS debugging system debugging tool for debugging a vehicle-mounted operating system provided by an embodiment of the present disclosure
  • Fig. 11 is a structural block diagram of an electronic device provided by an embodiment of the present disclosure.
  • Fig. 12 is a structural block diagram of a server provided by an embodiment of the present disclosure.
  • the existing vehicle operating system includes user space and kernel space.
  • User space includes application program module, whitelist management module, configuration management module and audit log generation module.
  • Kernel space includes system call layer, autonomous access control module, mandatory access control module , trusted measurement module, application program loading module and policy cache management module; the whitelist management module is connected with the application program module and the configuration management module, and the trusted measurement module is used to perform trusted measurement on application program files, so that the kernel space can judge whether You can continue loading applications.
  • the existing vehicle-mounted operating system only includes user space and kernel space.
  • the frame design of the vehicle-mounted system is general and single, and there is no supporting vehicle-mounted development-related debugging system, which has not been applied to the actual vehicle. And the use of single-chip bare-metal programming has many disadvantages such as poor code maintainability, poor program scalability, and poor project portability.
  • FIG. 1 shows an exemplary structural diagram of a vehicle operating system provided according to an embodiment of the present disclosure.
  • the vehicle-mounted operating system provided by the present disclosure includes a hardware layer, a software layer, and an application layer arranged sequentially from bottom to top; wherein,
  • the hardware layer includes at least one controller hardware, each controller hardware includes a processor;
  • the software layer includes a BEOS operating system and a BEOS driver; wherein, the BEOS operating system is used to manage and control the hardware and software resources of the computer system, and the BEOS driver is used to complete data transmission between the hardware layer and the software layer;
  • the application layer includes multiple application programs, which are connected to the BEOS operating system through an operating system interface, and each application program is used to provide vehicle-related applications.
  • the hardware layer is used to provide vehicle-related hardware, and the hardware layer includes at least one controller hardware, such as a single-chip microcomputer, and each controller hardware includes a processor.
  • Multiple applications and the BEOS (Be Operating System, Operating System) operating system are connected through the Portable Operating System Interface (POSIX) operating system interface.
  • POSIX Portable Operating System Interface
  • the POSIX (Portable Operating System Interface, Portable Operating System Interface) standard defines the operating system
  • the interface standard that should be provided for the application program is defined by IEEE (Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers) for software to run on various UNIX (Uniplexed Information and Computing System, UNIX operating systems)
  • IEEE Institute of Electrical and Electronics Engineers
  • UNIX Uniplexed Information and Computing System, UNIX operating systems
  • the general term for a series of API Application Programming Interface, Application Programming Interface
  • the vehicle-mounted operating system uses the self-developed embedded BEOS operating system combined with the single-chip microcomputer.
  • the BEOS operating system runs on multiple single-chip microcomputers and other hardware.
  • the BEOS operating system is used to manage and control the computer program of the hardware and software resources of the computer system. It is also the core and cornerstone of the computer system.
  • the BEOS operating system can handle things such as managing and configuring memory, determining system resources Priority of supply and demand, control of input and output devices, operation of the network and management of file systems and other basic affairs, and the BEOS operating system can provide an operation interface for users to interact with the system; code maintainability of the BEOS operating system, program scalability The performance and portability of the project are good, and the cost is low.
  • the BEOS operating system provided by the embodiment of the present disclosure can be fully graphical, has good system stability and high operating efficiency, can support 64-bit file systems and multi-processors, and integrates powerful multimedia software, BEOS It allows simultaneous operation of multiple audio, video, image, and network-based application software, and the memory and processor will always be kept in the most stable operating state, and the quality of multimedia will not change at all; and it has perfect network functions. Full-featured network software.
  • the BEOS operating system includes a task layer, an intermediate protocol stack layer, and an OS Kernel (Operating System Kernel, operating system kernel) layer.
  • OS Kernel Operating System Kernel, operating system kernel
  • the task layer includes a work task module and a system monitoring task module; wherein the work task module includes at least one main task unit, and each main task unit is communicatively connected to at least one sub-task unit;
  • the intermediate protocol stack layer includes at least one of the following: file system module, TCP/IP protocol module, Bluetooth protocol stack module, signal management module, network management module, CAN service module and data persistence management module;
  • the OS kernel layer includes at least one of the following: a task management module, a task communication module, a memory management module, a memory runtime module, a timer management module, a synchronization management module and an interrupt management module.
  • the intermediate protocol stack layer is used to provide various services of the vehicle operating system, and each module is used to provide corresponding file system, TCP/IP (Transmission Control Protocol/Internet Protocol) protocol, Bluetooth protocol stack, signal management, network management, CAN (Controller Area Network, Controller Area Network) service and data persistence management, etc.
  • the file system is the method and data structure used by the operating system to specify the files on the disk or partition; that is, the method of organizing files on the disk. It also refers to the disk or partition used to store files, or the type of file system; the software organization responsible for managing and storing file information in the operating system is called a file management system, or file system for short.
  • TCP/IP refers to a protocol cluster that can realize information transmission between multiple different networks, and is composed of the IP protocol at the network layer and the TCP protocol at the transport layer.
  • the goal of the Bluetooth protocol specification is to allow applications that follow the specification to interoperate.
  • CAN service management is responsible for implementing network management services and coordinating the wake-up and sleep state switching of the CAN network.
  • the network management module is composed of four modules: ComM (Communication Manager, communication manager), general network manager interface, bus-related network manager, and bus-related state manager. ) in the development process, the network management module is to reduce power consumption, and various communication buses can choose to sleep or work normally according to the function under specific circumstances, and realize the communication between specific ECUs under specific functions by distinguishing different communication bus structures, without The ECU that needs to participate in this function can go to sleep to reduce energy consumption, and the network management module coordinates the sleep and wake-up of the whole vehicle.
  • ComM Communication Manager
  • general network manager interface Bus-related network manager
  • bus-related state manager bus-related state manager
  • Data persistence management includes the following functions: 1) API interface: implement the API interface of KEY-VALUE type and file type, including writing interface and reading interface; 2) data verification, master-slave backup : The system development and design engineer writes the master and slave backup paths into the configuration file (XML format) through the configuration tool, and the data persistence storage management is responsible for adding the verification code (KEY-VALUE type data) to the application or service data to be written, 3) Data verification and recovery: When an application or service reads KEY-VALUE data through the reading interface, the data persistent storage management will read the data and the corresponding verification code together and verify the data; if the verification fails, the data in the backup area needs to be read and restored after verification; if the data in the backup area also fails to verify, an error code will be returned
  • Each module in the OS kernel (Kernel) layer is used to provide task management, inter-task communication mechanism, memory management and runtime library, timer management, synchronization management and interrupt management.
  • Task management is mainly responsible for creating/deleting user tasks and scheduling.
  • Inter-task communication is responsible for synchronization between tasks and data transfer between tasks. For example, multiple subtasks can send different messages to the message queue of a subtask, or a subtask can send different messages to the message queues of different subtasks.
  • Memory management is responsible for allocating and reclaiming embedded memory.
  • Timer management is responsible for executing user-defined functions within the time specified by the user. The timer service provides software timers for applications and basic software.
  • Synchronization management means that in a job, there may be an assisting relationship between several subtasks, that is, one subtask must wait for another subtask to complete a certain event before proceeding, then it involves the coordination between subtasks
  • the synchronization problem is shown in Figure 5 below.
  • Interrupt management is mainly responsible for setting the user interrupt function. When the hardware is interrupted, the interrupt function set by the user can be executed immediately, or when the hardware is abnormal, it can correctly handle these exceptions.
  • the system monitoring task unit in the task layer is used for real-time monitoring of the computer system.
  • the main task unit is used to provide centralized resource management and subtask unit management
  • the resource centralized management includes at least one of the following contents: timer, message queue, semaphore, waiting list, application and release of hardware resources;
  • the subtask unit management includes at least one of the following contents: subtask creation, subtask deletion, subtask state control, and subtask state monitoring.
  • Each project work of the vehicle-mounted operating system of the present disclosure can be defined as a main task and several subtasks.
  • the function of the main task is resource centralized management and subtask management.
  • the main task can determine the sequence and order of subtask creation/deletion according to the needs of the project.
  • resource centralized management includes application and release of timers, message queues, semaphores, waiting lists, hardware and other related resources;
  • subtask management mainly includes subtask creation/deletion, subtask status control, subtask status monitoring and inspection .
  • the information station includes two subtasks, one subtask is the module command sending subtask of 3G/4G/5G, and the other subtask is the data receiving subtask;
  • the sending subtask sends a command to the device (referring to the BEOS operating system OS kernel timer, task manager, memory management, etc.), must wait for the serial port data receiving subtask to return to the status of the command execution result before continuing to execute.
  • the task synchronization method of the vehicle-mounted operating system of the present disclosure includes the following steps:
  • the serial port data receiving subtask receives, parses the serial port data, and completes the event, activates the task waiting for the event through Wakeup (event name).
  • a subtask When a subtask needs to transfer data to another subtask, it can be done through the message queue. For example, multiple subtasks can send different message queues to the message queue of a subtask, including the following substeps:
  • S201 The main task creates a message queue used by the subtasks through CreateMQ().
  • S202 Multiple subtasks of messages to be sent respectively provide SendMsg() through the underlying OS kernel to transmit the message data to the message queue.
  • S203 The subtask to receive the message receives message data from the message queue through ReceiveMsg().
  • a subtask sends different message queues to message queues of different subtasks; specifically includes the following substeps:
  • S301 The main task creates multiple message queues used by the subtasks through CreateMQ().
  • a subtask of a message to be sent transmits the message data to multiple message queues through the underlying OS kernel respectively providing SendMsg().
  • the subtasks designed by the vehicle-mounted operating system of the present disclosure process messages in the following manner: regularly check whether there is a message in the message queue, and if there is a message in the message queue, the retrieve the message from the queue, process the message according to the protocol defined by each application, and then continue; if there is no message in the message queue, the subtask sleeps and waits until a message arrives from other tasks, then wakes up and processes the message.
  • the BEOS driver includes at least one of the following drivers: serial port driver, CAN driver, SPI driver, Flash driver, I2C driver and RTC driver.
  • the BEOS driver in Figure 1 corresponds to the device driver interface in Figure 2, and the BEOS driver includes a serial port driver, CAN driver, and SPI (Serial Peripheral interface, serial peripheral device Interface) driver, Flash (Flash EEPROM, flash memory) driver, I2C (Inter-Integrated Circuit, I2C bus) driver and RTC (Real_Time Clock, real-time clock) driver.
  • SPI Serial Peripheral interface, serial peripheral device Interface
  • Flash Flash EEPROM, flash memory
  • I2C Inter-Integrated Circuit
  • I2C bus Inter-Integrated Circuit
  • RTC Real_Time Clock, real-time clock
  • each driver in the BEOS driver includes four parts, respectively: 1) driver interface: the task realizes data interaction with the hardware through the driver interface, different hardware, the driver interface is different 2) Intermediate logical layer: a) Logical control, which deals with protocol/standard-related content, such as CAN classification processing, data verification; b) Synchronous control, which is to perform synchronous control when multiple tasks access the hardware at the same time ; c) Buffer management, which is to buffer the data generated by the device to prevent data overflow; 3) Hardware interface: the driver realizes the operation of the hardware through the hardware interface, and the hardware interface is related to the platform; 4) The driver and other components: Such as timers, synchronization, communication, etc.
  • CAN Controller Area Network
  • BOSCH Controller Area Network
  • ISO 11898 International Standard
  • FIG. 9 it is a diagram showing an example of a vehicle operating system CAN drive.
  • the CAN driver is a shared device, and the design driver is that multiple tasks can read and write CAN devices at the same time.
  • the prerequisites are: call InitCan() when the platform is initialized to initialize the CAN hardware; register the CAN interrupt service program; create a data sending timer.
  • CAN driver interface open OpenCan (Can Id), write WriteCan (CanHandle, type Type, data Data, Len), read ReadCan (CanHandle, data Data, Len), close CloseCan (CanHandle), set SetCan (CanHandle, type Type, data Data); set and adjust the buffer size, cancel can data transmission, etc., get GetCan(CanHandle, type Type, data Data); reset ResetCan(CanHandle);
  • Read and write logic control read ReadCan, write WriteCan;
  • Hardware interface _WriteCan, Can interrupt service routine.
  • application tasks and CAN driver interface data transmission in which WriteCan in the CAN driver interface is controlled by logic, and firstly classified, such as 3 events, 3 event cycles + 1 time in 2 seconds, 1 cycle per second, and 1 trigger time, etc., through Timer management, write protection, write register, transfer to CAN hardware, transfer to CAN interrupt service program, apply through CAN buffer management, search/insert data into CAN buffer, and finally ReadCan.
  • the vehicle-mounted operating system in the prior art is only the interface between the user and the vehicle-mounted hardware, and is also the interface between the vehicle-mounted hardware and the upper-layer software.
  • the vehicle-mounted operating system proposed in this disclosure is divided into three levels: hardware layer, software layer and application layer. The design of the three levels It can be more convenient to maintain and develop the vehicle application software, and the three levels perform their own duties, making the vehicle operating system more real-time and stable, and more secure.
  • the vehicle-mounted operating system proposed in this disclosure introduces the implementation method and specific implementation process in more detail, and has been practically applied in vehicles.
  • FIG. 1 another aspect of the present disclosure provides a BEOS debugging system.
  • the BEOS debugging system runs on a PC and is used for developing, verifying, debugging, and maintaining a vehicle-mounted operating system.
  • the vehicle-mounted operating system provided by the embodiments of the present disclosure is equipped with a corresponding BEOS debugging system.
  • the BEOS debugging system can be used for more effective development, verification, debugging, maintenance, etc., so that the vehicle-mounted software can be
  • the self-developed vehicle-mounted operating system can be better developed and debugged.
  • the vehicle-mounted operating system provided by the embodiments of the present disclosure can be directly applied to the car, and can also be opened to third parties such as individuals, departments, and manufacturers. On-board related software development.
  • FIG. 10 Please refer to FIG. 10 for a tool diagram of a BEOS debugging system for debugging a vehicle-mounted operating system.
  • the BEOS debugging system runs on the personal computer (PC) side and is divided into four functional modules, as follows:
  • the communication protocol processing module is used to provide communication data processing between the BEOS debugging system on the PC side and the BEOS operating system running on the single-chip microcomputer;
  • the source code processing module is used to provide functions such as source code data structure analysis, source code display, and source code location; source code data structure analysis is used to analyze the data structures of the code, and source code display is used to display the source code of the written code , the source code location is used to directly locate the definition of the function, variable, structure, parameter, etc. to be found.
  • the debugging element analysis module is used to provide the variable display function that needs to be debugged, such as register display, global variable display, local variable display, stack information display, function call sequence display, etc., so that developers can know the running status of the program and the hardware driver in real time.
  • the state of the software and the running state of the software if there is an error, it can be adjusted and modified in time.
  • the user operation interface module (GUI, Graphical User Interface, graphical user interface) is used to provide the user operation interface.
  • GUI Graphical User Interface
  • the user operation interface is the intermediary for the interaction and communication between the user and the hardware and software. Through the user operation interface, the user sends the software to execute a certain Functional instructions, the software uses hardware and other software to execute the instructions, and returns the execution results to the user in the form of text or graphics.
  • the compilation function of the source code of the vehicle-mounted operating system of the present disclosure is composed of three parts: source code compilation, compilation information window and error definition.
  • the programming of the vehicle-mounted operating system software of the present disclosure can call the programming tool to perform source code programming, and can also generate an official release version through the source code for programming and upgrading.
  • the debugging of the vehicle-mounted operating system of the present disclosure includes four parts: registers, local variables, global variables, and task states, which is convenient for program developers to develop vehicle-mounted applications.
  • vehicle-mounted operating system proposed in this disclosure is not limited to the development of automotive applications, and can also be used in the development of related application software such as future autonomous driving, development of drones, aircraft, and ships.
  • an embodiment of the present disclosure provides a BEOS debugging method, including the following steps:
  • the BEOS debugging system sends debugging instructions to the vehicle operating system
  • the on-board operating system debugs the object to be debugged according to the debugging instructions
  • the object to be debugged runs according to the debugging instructions, and feeds back the running results to the BEOS debugging system;
  • the BEOS debugging system determines the performance of the object to be debugged according to the running results of the object to be debugged.
  • the controller when the controller is installed in the car, the controller does not run according to the designed mode. For example, the steps of the window are not correct.
  • the original design is to upgrade to the full warehouse and the result is only half warehouse.
  • the developer can check the program through the BEOS debugging system. The logic, the state of the window program, etc. are printed out to check and adjust accordingly.
  • FIG. 11 is a structural block diagram of an electronic device provided by an embodiment of the present disclosure.
  • the electronic device 401 includes a processor 4011 and a memory 4012, where the processor 4011 may include one or more processing cores, such as a 4-core processor, an 8-core processor, and the like.
  • the processor 4011 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field Programmable Gate Array, FPGA), programmable logic array (Programmable Logic Array, PLA) .
  • DSP Digital Signal Processing
  • FPGA Field Programmable Gate Array
  • PLA programmable logic array
  • the processor 4011 may also include a main processor and a coprocessor, and the main processor is a processor for processing data in a wake-up state, also called a central processing unit (Central Processing Unit, CPU); a coprocessor It is a low-power processor for processing data in the standby state.
  • main processor is a processor for processing data in a wake-up state, also called a central processing unit (Central Processing Unit, CPU); a coprocessor It is a low-power processor for processing data in the standby state.
  • CPU central processing unit
  • coprocessor It is a low-power processor for processing data in the standby state.
  • the processor 4011 may be integrated with a graphics processor (Graphics Processing Unit, GPU), and the GPU is used to render and draw the content to be displayed on the display screen.
  • the processor 4011 may also include an artificial intelligence (Artificial Intelligence, AI) processor, and the AI processor is used to process computing operations related to machine learning.
  • AI Artificial Intelligence
  • Memory 4012 may include one or more computer-readable storage media, which may be non-transitory. Memory 4012 may also include high-speed random access memory, and non-volatile memory, such as one or more magnetic disk storage electronic devices, flash memory storage electronic devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 4012 is used to store at least one instruction, and the at least one instruction is used to be executed by the processor 4011 to implement the text provided in the method embodiments of the present disclosure Show method.
  • the electronic device 401 may further include a peripheral electronic device interface 4013 and at least one peripheral electronic device.
  • the processor 4011, the memory 4012, and the peripheral electronic device interface 4013 may be connected through buses or signal lines.
  • Each peripheral electronic device can be connected to the peripheral electronic device interface 4013 through a bus, a signal line or a circuit board.
  • the peripheral electronic equipment includes but not limited to a radio frequency circuit 4014 , a touch screen 4015 and a power supply 4016 .
  • the peripheral electronic device interface 4013 may be used to connect at least one peripheral electronic device related to input/output (Input/Output, I/O) to the processor 4011 and the memory 4012 .
  • the processor 4011, memory 4012 and peripheral electronic device interface 4013 are integrated on the same chip or circuit board; in some other embodiments, any of the processor 4011, memory 4012 and peripheral electronic device interface 4013 One or both of them may be implemented on a separate chip or circuit board, which is not limited in this embodiment of the present disclosure.
  • the radio frequency circuit 4014 is used to receive and transmit radio frequency (Radio Frequency, RF) signals, also called electromagnetic signals.
  • the radio frequency circuit 4014 communicates with the communication network and other communication electronic devices through electromagnetic signals.
  • the radio frequency circuit 4014 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals into electrical signals.
  • the radio frequency circuit 4014 includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and the like.
  • the radio frequency circuit 4014 can communicate with other electronic devices through at least one wireless communication protocol.
  • the wireless communication protocol includes but is not limited to a metropolitan area network, various generations of mobile communication networks (2G, 3G, 4G and 5G), a wireless local area network and/or a wireless fidelity (Wireless Fidelity, WiFi) network.
  • the radio frequency circuit 4014 may also include circuits related to Near Field Communication (NFC).
  • NFC Near Field Communication
  • the touch screen 4015 is used to display a user interface (User Interface, UI).
  • the UI can include graphics, text, icons, video, and any combination thereof.
  • the touch display 4015 is a touch display, the touch display 4015 also has the ability to collect touch signals on or above the surface of the touch display 4015 .
  • the touch signal can be input to the processor 4011 as a control signal for processing.
  • the touch display screen 4015 can also be used to provide virtual buttons and/or virtual keyboards, also called soft buttons and/or soft keyboards.
  • touch display screen 4015 there may be one touch display screen 4015, which is arranged on the front panel of the electronic device 401; in other embodiments, there may be at least two touch display screens 4015, which are respectively arranged on different surfaces or Folding design; in some other embodiments, the touch display screen 4015 may be a flexible display screen, which is arranged on the curved surface or the folding surface of the electronic device 401 . Even, the touch display screen 4015 can also be set as a non-rectangular irregular figure, that is, a special-shaped screen.
  • the touch display screen 4015 can be made of liquid crystal display (Liquid Crystal Display, LCD), organic light-emitting diode (Organic Light-Emitting Diode, OLED) and other materials.
  • FIG. 11 does not constitute a limitation on the electronic device 401, and may include more or less components than shown in the figure, or combine certain components, or adopt a different component arrangement.
  • the electronic device 401 also includes one or more programs, the one or more programs are stored in the memory 4012, and are configured to be executed by the one or more processors 4011, and the one or more programs Instructions for performing the task synchronization, communication and driving methods in the vehicle-mounted operating system executed by the above-mentioned electronic device provided by the embodiments of the present disclosure, and the BEOS debugging method are included.
  • the server 402 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (Central Processing Units, CPU) 4021 (for example, one or more processors) And memory 4022, one or more storage media 4025 for storing application programs 4023 or data 4024 (such as one or more mass storage electronic devices).
  • the memory 4022 and the storage medium 4025 may be temporary storage or persistent storage.
  • the program stored in the storage medium 4025 may include one or more modules (not shown in the figure), and each module may include a series of instructions to operate on the computer system.
  • the central processing unit 4021 may be configured to communicate with the storage medium 4025 , and execute a series of instruction operations in the storage medium 4025 on the server 402 .
  • the server 402 can also include one or more power supplies 4026, one or more wired or wireless network interfaces 4027, one or more input and output interfaces 4028, and/or, one or more operating systems 4029, such as BEOS, Windows ServerTM , Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.
  • one or more power supplies 4026 such as BEOS, Windows ServerTM , Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.
  • the embodiments of the present disclosure provide a computer-readable storage medium for storing program codes, and the program codes are used to execute the task synchronization, communication and driving methods in the vehicle-mounted operating systems of the foregoing embodiments, and BEOS debugging any one of the methods.
  • an embodiment of the present disclosure provides a computer program product including instructions, which, when run on a computer, cause the computer to execute the task synchronization, communication and driving methods in the vehicle-mounted operating system of the foregoing embodiments, as well as the BEOS debugging any one of the methods.
  • the disclosed system, device and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of modules is only a logical function division. In actual implementation, there may be other division methods.
  • multiple modules or components can be combined or integrated. to another system, or some features may be ignored, or not implemented.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or modules may be in electrical, mechanical or other forms.
  • a module described as a separate component may or may not be physically separated, and a component shown as a module may or may not be a physical unit, that is, it may be located in one place, or may be distributed to multiple network units. Part or all of the modules can be selected according to actual needs to realize the effect of the solution of this embodiment.
  • each functional module in each embodiment of the present disclosure may be integrated into one processing unit, each module may exist separately physically, or two or more units may be integrated into one module.
  • the above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units. However, if an integrated unit is realized in the form of a software function unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.
  • the part of the technical solution of the present disclosure that contributes to the prior art or all or part of the technical solution may be embodied in the form of a software product.
  • the computer software product is stored in a storage medium and includes several instructions It is used to make a computer electronic device (which may be a personal computer, a server, or a network electronic device, etc.) execute all or part of the steps of the information reporting method of each embodiment of the present disclosure.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disc and other media that can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

一种车载操作系统、调试系统及方法、电子设备及存储介质，该车载操作系统包括硬件层、软件层和应用层; 其中，硬件层包括至少一个控制器硬件，每个控制器硬件包括一个处理器; 软件层包括 BEOS 操作系统和 BEOS 驱动; BEOS 操作系统用于管理和控制计算机系统的硬件和软件资源，BEOS 驱动用于完成硬件层与软件层之间数据传送；应用层包括多个应用程序，每个应用程序用于提供车载相关的应用。利用自主开发的嵌入式 BEOS 操作系统，使得本公开提供的车载操作系统的实时性和稳定性更好，安全性更强。另外，为车载操作系统配置有相应的 BEOS 调试系统，能够更好的进行车载软件开发、验证、调试、维护等。

Description

车载操作系统、调试系统及方法、电子设备及存储介质
相关申请的交叉引用
本公开要求于2021年12月30日提交的申请号为202111663812.0、名称为“车载操作系统、调试系统及方法、电子设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本公开中。
技术领域
本公开一般涉及车载技术领域，尤其涉及一种车载操作系统、调试系统及方法、电子设备及存储介质。
背景技术
现有的车载操作系统的框架设计笼统、单一，如：很多车载软件都是应用单片机作为控制器。采用单片机裸机编程方式，虽然可以节约成本，但是这种开发模式有很大的缺点，首先代码的可维护性差，其次程序的可扩展性差，最后项目的可移植性差，加上全球对知识产权的越发重视，未来的某一天或许当前免费使用的软件不将继续免费，间接增加了使用成本费，以及增加了车企的成本。
发明内容
一种车载操作系统、调试系统及方法、电子设备及存储介质，利用自主开发的嵌入式BEOS操作系统，使得本公开实施例提供的车载操作系统的实时性和稳定性更好，安全性更强。另外，为车载操作系统配置有相应的BEOS调试系统，使车载软件在自主开发的车载操作系统上能够进行更好的开发、验证、调试、维护等。
第一方面，本公开提出了一种车载操作系统，包括由下而上依次设置的硬件层、软件层和应用层；其中，
所述硬件层包括至少一个控制器硬件，每个所述控制器硬件包括一个处理器；
所述软件层包括BEOS操作系统和BEOS驱动；其中，所述BEOS操作系统用于管理和控制计算机系统的硬件和软件资源，所述BEOS驱动用于完成硬件层与软件层之间数据传送；
所述应用层包括多个应用程序，多个所述应用程序与所述BEOS操作系统通过操作系统接口连接，每个所述应用程序用于提供车载相关的应用。
根据本公开实施例的车载操作系统，通过利用自主开发的嵌入式BEOS操作系统，使 得本公开实施例提供的车载操作系统的实时性和稳定性更好，安全性更强。
第二方面，本公开提出了一种BEOS调试系统，所述BEOS调试系统运行于PC端，用于对车载操作系统进行开发、验证、调试、维护。
根据本公开实施例的BEOS调试系统，通过为车载操作系统配置有相应的BEOS调试系统，使车载软件在自主开发的车载操作系统上能够进行更好的开发、验证、调试、维护等，另外，
第三方面，本公开提出了一种BEOS调试方法，包括：
BEOS调试系统向车载操作系统发送调试指令；
所述车载操作系统根据所述调试指令对待调试对象进行调试；
所述待调试对象根据所述调试指令运行，并将运行结果反馈给所述BEOS调试系统；
所述BEOS调试系统根据所述待调试对象的运行结果确定所述待调试对象的性能。
根据本公开实施例的BEOS调试方法，开发者就可以通过BEOS调试系统查看程序的逻辑，车窗程序的状态等打印出来查看一下进行相应的调整测试。
第四方面，本公开提出了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如本公开各实施例提供的BEOS调试方法的步骤，以及车载操作系统中的任务同步、通信和驱动方法的步骤。
第五方面，本公开提出了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如本公开各实施例提供的BEOS调试方法的步骤，以及车载操作系统中的任务同步、通信和驱动方法的步骤。
附图说明
通过阅读参考以下附图所作的对非限制性实施例所作的详细描述，本公开附加的方面和优点将会变得更明显：
图1为本公开实施例提供的一种车载操作系统与BEOS调试系统相结合的架构图；
图2为本公开实施例提供的BEOS操作系统与对应的BEOS驱动相结合的具体架构图；
图3为本公开实施例提供的数据持久化管理模块的结构图；
图4为本公开实施例提供的一种车载操作系统的任务框架图；
图5为本公开实施例提供的一种车载操作系统的任务同步图；
图6为本公开实施例提供的一种车载操作系统的第一种实施方式的任务通信图；
图7为本公开实施例提供的一种车载操作系统的第二种实施方式的任务通信图；
图8为本公开实施例提供的一种车载操作系统的BEOS驱动图；
图9为本公开实施例提供的CAN驱动示例图；
图10为本公开实施例提供的用于调试车载操作系统的BEOS调试系统调试工具图；
图11为本公开实施例提供的一种电子设备的结构框图。
图12为本公开实施例提供的一种服务器的结构框图。
具体实施方式
下面结合附图和实施例对本公开作详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。
需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
现有的车载操作系统包括用户空间和内核空间，用户空间包括应用程序模块、白名单管理模块、配置管理模块以及审计日志生成模块，内核空间包括系统调用层、自主访问控制模块、强制访问控制模块、可信度量模块、应用程序装载模块以及策略缓存管理模块；白名单管理模块与应用程序模块以及配置管理模块连接，可信度量模块用于对应用程序文件进行可信度量，使内核空间判断是否可以继续装载应用程序。现有的车载操作系统只包括用户空间和内核空间两部分，车载系统框架设计笼统、单一，且没有配套车载开发相关的调试系统，并未应用在实车上。且采用单片机裸机编程方式具有代码的可维护性差、程序的可扩展性差、项目的可移植性差等诸多缺点。
请参考图1，示出了根据本公开实施例提供的车载操作系统的示例性结构图。
如图1所示，在本实施例中，本公开提供的车载操作系统包括由下而上依次设置的硬件层、软件层和应用层；其中，
硬件层包括至少一个控制器硬件，每个控制器硬件包括一个处理器；
软件层包括BEOS操作系统和BEOS驱动；其中，BEOS操作系统用于管理和控制计算机系统的硬件和软件资源，BEOS驱动用于完成硬件层与软件层之间数据传送；
应用层包括多个应用程序，多个应用程序与BEOS操作系统通过操作系统接口连接，每个应用程序用于提供车载相关的应用。
具体的，硬件层用于提供车载相关的硬件，硬件层包括至少一个控制器硬件，比如单片机，每个控制器硬件包括一个处理器。多个应用程序与BEOS(Be Operating System，操作系统)操作系统之间通过便携式操作系统接口(POSIX)操作系统接口通信连接，POSIX(Portable Operating System Interface，可移植操作系统接口)标准定义了操作系统 应该为应用程序提供的接口标准，是IEEE(Institute of Electrical and Electronics Engineers，电气与电子工程师协会)为要在各种UNIX(Uniplexed Information and Computering System，UNIX操作系统)上运行的软件而定义的一系列API(Application Programming Interface，应用程序编程接口)标准的总称。针对现有车载系统中单片机裸机编程方式的缺陷，本实施例提供的车载操作系统利用自主开发了嵌入式BEOS操作系统与单片机相结合的方式，BEOS操作系统运行在多个单片机等硬件上，单片机用于进行车载软件的开发，BEOS操作系统用于管理和控制计算机系统的硬件与软件资源的计算机程序，同时也是计算机系统的内核与基石，BEOS操作系统能够处理如管理与配置内存、决定系统资源供需的优先次序、控制输入与输出设备、操作网络与管理文件系统等基本事务，且BEOS操作系统能提供一个让用户与系统交互的操作界面；BEOS操作系统的代码可维护性、程序的可扩展性、项目的可移植性均较好，且成本低廉。
需要说明的是，本公开实施例提供的BEOS操作系统能够做到全图形化，系统的稳定性好以及运行效率高，能够支持64位文件系统及多处理器，集成了强大的多媒体软件，BEOS允许同时操作多个音频、视频、图像以及基于网络的应用软件，而且内存及处理器将始终保持在最稳定的运行状态下，多媒体的品质也丝毫不会改变；且具有完善的网络功能，拥有功能全面网络软件。
请参考图2所示的一种车载操作系统的静态框架图，本公开实施例中，BEOS操作系统包括由上而下依次设置的任务层、中间协议栈层和OS Kernel(Operating System Kernel，操作系统内核)层。
具体地，参考图2，任务层包括工作任务模块和系统监控任务模块；其中，工作任务模块包括至少一个主任务单元，每个主任务单元与至少一个子任务单元通信连接；
中间协议栈层包括至少如下一项：文件系统模块、TCP/IP协议模块、蓝牙协议栈模块、信号管理模块、网络管理模块、CAN服务模块和数据持久化管理模块；
OS内核层包括至少如下一项：任务管理模块、任务通信模块、内存管理模块、内存运行库模块、定时器管理模块、同步管理模块和中断管理模块。
具体的，中间协议栈层用于提供车载操作系统的各种服务，各个模块用于对应提供文件系统、TCP/IP(Transmission Control Protocol/Internet Protocol)协议、蓝牙协议栈、信号管理、网络管理、CAN(Controller Area Network，控制器局域网络)服务和数据持久化管理等。其中，文件系统是操作系统用于明确磁盘或分区上的文件的方法和数据结构；即在磁盘上组织文件的方法。也指用于存储文件的磁盘或分区，或文件系统种类；操作系统中负责管理和存储文件信息的软件机构称为文件管理系统，简称文件系统。TCP/IP是指能够在多个不同网络间实现信息传输的协议簇，由网络层的IP协议和传输层 的TCP协议组成。蓝牙协议规范的目标是允许遵循规范的应用能够进行相互间操作。CAN服务管理负责实现网络管理服务，协调CAN网络的唤醒和休眠状态的切换。
网络管理模块由ComM(Communication Manager，通信管理器)、通用网络管理器接口、总线相关的网络管理器、总线相关的状态管理器四个模块组成，在汽车电子ECU(Electronic Control Unit，电子控制单元)开发过程中，网络管理模块在于减少功耗，各种通信总线在特定的情况下根据功能选择休眠还是正常工作，通过区分不同的通信总线结构实现特定功能下特定ECU之间的通信，而不需要参加该功能的ECU就可以进入休眠，减少能量损耗，网络管理模块协调整车的休眠唤醒等。
在域控制器应用、服务开发过程中，各服务和应用都会有永久存储数据的需求；数据持久化管理就是为了简化服务和应用对数据存储的编程，为服务和应用提供统一的数据存储API；数据持久化管理，如下图3所示，包括如下功能：1)API接口：实现KEY-VALUE类型、文件类型的API接口，包括写入接口和读取接口；2)数据校验、主从备份：系统开发设计工程师通过配置工具，将主、从备份路径写入配置文件(XML格式)，数据持久化存储管理负责将应用或服务待写数据，加入校验码(KEY-VALUE类型数据)，一并存储到主、从备份区；3)数据校验与恢复：当应用或服务通过读取接口读取KEY-VALUE数据时，数据持久化存储管理将数据和对应的校验码一并读取，并对数据进行校验；如果校验失败，需读取备份区数据，校验后恢复；如备份区数据也校验失败，则返回错误码给调用者；4)应用数据隔离：各服务、应用数据分开存储；一个应用、服务根据应用、服务名存储到一个KEY-VALUE类型的文件中。
OS内核(Kernel)层中的各个模块用于对应提供任务管理、任务间通信机制、内存管理和运行库、定时器管理、同步管理和中断管理等。任务管理主要负责创建/删除用户任务、调度。任务间通信负责任务之间同步，以及任务间数据传递，如多个子任务可将不同消息发送到一个子任务的消息队列，也可以一个子任务发送不同消息到不同子任务的消息队列。内存管理负责对嵌入式内存进行分配回收管理。定时器管理负责在用户规定的时间内执行用户定义功能函数，定时器服务提供用于应用程序和基本软件的软件定时器。同步管理为在一个工作中，几个子任务之间可能存在一种协助关系，即一个子任务必须等到另一个子任务完成某件事件后才能继续往下进行，则就涉及到子任务之间的同步问题，具体如下图5所示。中断管理主要负责设置用户中断函数，当硬件发生中断后，能立即执行用户设置的中断函数，或者当硬件发生异常后，能正确处理这些异常。任务层中的系统监控任务单元用于对计算机系统进行实时监控。
在一个实施例中，主任务单元用于提供资源集中管理和子任务单元管理；
其中，资源集中管理包括至少如下一项内容：定时器、消息队列、信号量、等待列表、 硬件资源的申请和释放；
子任务单元管理包括至少如下一项内容：子任务创建、子任务删除、子任务状态控制、子任务状态监控。
请参考图4所示的一种车载操作系统的任务框架图。
本公开的车载操作系统每一个项目工作可定义为一个主任务和若干个子任务，主任务功能是资源集中管理和子任务管理，主任务可根据项目中需要，决定子任务创建/删除的先后顺序和互斥关系，资源集中管理包括定时器、消息队列、信号量、等待列表、硬件等相关资源的申请和释放；子任务管理主要包括子任务创建/删除，子任务状态控制，子任务状态监控检查。
请参考图5所示的一种车载操作系统的任务同步图。
在一个工作中，几个子任务之间可能存在一种协助关系，即一个子任务必须等到另一个子任务完成某种事件后才能继续往下进行，这里面就涉及到子任务之间的同步问题。
例如：信息站包括两个子任务，一个子任务是3G/4G/5G等模块命令发送子任务，一个子任务是数据接收子任务；发送子任务发送一个命令给设备(指BEOS操作系统OS内核里面的定时器、任务管理器、内存管理等)后，必须等待串口数据接收子任务返回命令执行结果状态后才能继续往下执行。
具体的，本公开的车载操作系统的任务同步方法包括以下步骤：
S101：定义一个同步事件。
S102：命令发送子任务发送命令后，通过WaitEvent(事件名)等待串口数据接收子任务完成该事件。
S103：串口数据接收子任务接收，解析串口数据后，完成该事件后，通过Wakeup(事件名)，激活正等待该事件的任务。
S104：两个子任务继续运行。
请参考图6所示的一种车载操作系统的第一种实施方式的任务通信图。
当子任务有数据需要传输到另一个子任务时，可通过消息队列的方式进行，比如多个子任务可将不同消息队列发送到一个子任务的消息队列，具体包括以下子步骤：
S201：主任务通过CreateMQ()创建子任务使用的消息队列。
S202：多个待发送消息的子任务分别通过底层OS内核提供SendMsg()将消息数据传输到消息队列中。
S203：待接收消息的子任务通过ReceiveMsg()从消息列队中接收消息数据。
再比如，请参考图7所示的一种车载操作系统的第二种实施方式的任务通信图，一个子任务发送不同消息队列到不同子任务的消息队列；具体包括以下子步骤：
S301：主任务通过CreateMQ()创建子任务使用的多个消息队列。
S302：一个待发送消息的子任务分别通过底层OS内核提供SendMsg()将消息数据传输到多个消息队列中。
S303：多个待接收消息的子任务通过ReceiveMsg()从对应的每个消息列队中接收消息数据。
为了保证消息数据的准确性及资源的最大化利用，本公开的车载操作系统设计的子任务通过以下方式处理消息：定时查询消息队列是否有消息送达，如果消息列队中有消息，则从消息队列中检索出消息，根据各应用定义的协议处理该消息，然后继续；如果消息队列中没有消息，则子任务休眠等待，直到其他任务有一个消息送达，则被唤醒，处理该消息。
在一个实施例中，BEOS驱动至少包括如下一种驱动：串口驱动、CAN驱动、SPI驱动、Flash驱动、I2C驱动和RTC驱动。
具体的，参考图2所示的车载操作系统静态框架图，图1中的BEOS驱动对应图2中的设备驱动接口，BEOS驱动包括串口驱动、CAN驱动、SPI(Serial Peripheral interface，串行外围设备接口)驱动、Flash(Flash EEPROM，闪存)驱动、I2C(Inter-Integrated Circuit，I2C总线)驱动和RTC(Real_Time Clock，实时时钟)驱动。参考图8所示的车载操作系统驱动图，BEOS驱动中的每种驱动包括包括四个部分，分别为：1)驱动接口：任务通过驱动接口实现与硬件的数据交互，不同硬件，驱动接口不变；2)中间逻辑层：a)逻辑控制，是处理协议/规范相关的内容，例如CAN分类处理，数据校验；b)同步控制，是多个任务同时对硬件进行访问时，进行同步控制；c)缓冲区管理，是对设备产生的数据进行缓冲管理，防止数据溢出；3)硬件接口：是驱动通过硬件接口实现对硬件的操作，硬件接口与平台有关；4)驱动与其他组件：例如定时器、同步、通信等。
如以CAN驱动为例进行说明，CAN:控制器局域网络(Controller Area Network,CAN)的简称，是由以研发和生产汽车电子产品著称的德国BOSCH公司开发的，并最终成为国际标准(ISO 11898)，是国际上应用最广泛的现场总线之一。参考图9是一种车载操作系统CAN驱动示例图。CAN驱动是一个共享设备，设计驱动是多个任务可同时读写CAN设备。前提条件为：平台初始化时调用InitCan()，对CAN硬件进行初始化；注册了CAN中断服务程序；创建数据发送定时器。
CAN驱动接口：打开OpenCan(Can Id)、写入WriteCan(CanHandle,类型Type,数据Data,Len)、读取ReadCan(CanHandle,数据Data,Len)、关闭CloseCan(CanHandle)、设置SetCan(CanHandle,类型Type,数据Data)；设置调整缓冲区大小，取消can数据发送等，获取GetCan(CanHandle,类型Type,数据Data)；重置ResetCan(CanHandle)；
读写逻辑控制：读取ReadCan、写入WriteCan；
硬件接口：_WriteCan、Can中断服务程序。
比如应用任务和CAN驱动接口数据传输，其中CAN驱动接口中WriteCan通过逻辑控制，首先进行分类，比如事件3次、事件周期3次+2秒1次、周期1秒一次、触发1次等，通过定时器管理，写保护，写入寄存器，传输到CAN硬件，传输到CAN中断服务程序，通过CAN缓冲区管理申请、查找/插入数据进入CAN缓存区，最后ReadCan。
现有技术车载操作系统只是用户和车载硬件的接口，同时也是车载硬件和上层软件的接口，本公开提出的车载操作系统分成三个层次：硬件层、软件层和应用层，三个层次的设计能够更方便进行车载应用软件的维护和开发，三个层次各司其职，使得车载操作系统的实时性和稳定性更好，安全性更强。本公开提出的车载操作系统更加详细的介绍了实现方法和具体实现过程，且已经在汽车上进行了实际应用。
请参考图1，本公开的另外一个方面，提供一种BEOS调试系统，BEOS调试系统运行于PC端，用于对车载操作系统进行开发、验证、调试、维护。
具体的，本公开实施例提供的车载操作系统配套有相应的BEOS调试系统，在车载操作系统进行车载软件开发时通过BEOS调试系统进行更加有效的开发、验证、调试、维护等，使车载软件在自主开发的车载操作系统上能够进行更好的开发调试，本公开实施例提供的车载操作系统可以直接应用在汽车上，也可以开放给个人、部门、厂商等第三方，第三方在车载操作系统上进行车载相关的软件开发。
请参考图10所示的一种对车载操作系统进行调试的BEOS调试系统的工具图。
BEOS调试系统运行在个人计算机(PC)端，分为四个功能模块，具体如下：
通信协议处理模块，用于提供PC端BEOS调试系统与运行在单片机的BEOS操作系统通信数据处理；
源代码处理模块，用于提供源代码数据结构解析、源代码显示、源代码定位等功能；源代码数据结构解析用于分析该代码有哪些数据结构，源代码显示用于显示所编写的代码源码，源代码定位用于直接定位到所需要找的函数、变量、结构体、参数等的定义处。
调试元素解析模块，用于提供需要调试的变量显示功能，比如寄存器显示、全局变量显示、局部变量显示、堆栈信息显示、函数调用顺序显示等，能够使开发者实时知道程序运行的状态、硬件驱动的状态和软件的运行状态，出现错误可及时的进行调整修改。
用户操作界面模块(GUI，Graphical User Interface，图形用户界面)，用于提供用户操作界面，用户操作界面是用户与硬件、软件交互和通信的中介，通过用户操作界面，用户向软件发出执行某项功能的指令，该软件利用硬件、其他软件执行该指令，并以文字或图形的形式将执行结果返回给用户。
本公开的车载操作系统源代码的编译功能由源代码编译、编译信息窗口和错误定义三部分构成。
本公开的车载操作系统软件烧写可以调用烧写工具进行源代码烧写，也可通过源代码生成正式发布版本进行烧写升级等。
本公开的车载操作系统的调试包括寄存器、局部变量、全局变量、任务状态四个部分，方便程序开发者进行车载应用的开发。
本公开提出的一种车载操作系统应用范围不仅限于汽车应用开发，后续也可用于未来自动驾驶、无人机开发、飞机、轮船等与之相关的应用软件开发。
作为又一方面，本公开实施例提供一种BEOS调试方法，包括以下步骤：
BEOS调试系统向车载操作系统发送调试指令；
车载操作系统根据调试指令对待调试对象进行调试；
待调试对象根据调试指令运行，并将运行结果反馈给BEOS调试系统；
BEOS调试系统根据待调试对象的运行结果确定待调试对象的性能。
比如，当控制器装在车上后，控制器不按设计的模式运行，比如车窗的步骤不对，本来设计升全仓结果只升到半仓，开发者就可以通过BEOS调试系统查看程序的逻辑，车窗程序的状态等打印出来查看一下进行相应的调整测试。
基于前述实施例，请参考图11，其为本公开实施例提供的一种电子设备的结构框图。该电子设备401包括处理器4011和存储器4012，其中处理器4011可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器4011可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。
处理器4011也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称为中央处理器(Central Processing Unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。
另外，处理器4011可以集成有图像处理器(Graphics Processing Unit，GPU)，GPU用于对显示屏所需要显示的内容进行渲染和绘制。在一些实施例中，处理器4011还可以包括人工智能(Artificial Intelligence，AI)处理器，该AI处理器用于处理有关机器学习的计算操作。
存储器4012可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器4012还可以包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储电子设备、闪存存储电子设备。在一些实施例中，存储器4012中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器4011 所执行，以实现本公开方法实施例中提供的文本显示方法。
在一些实施例中，电子设备401还可以包括外围电子设备接口4013和至少一个外围电子设备。处理器4011、存储器4012和外围电子设备接口4013之间可以通过总线或信号线相连。各个外围电子设备可以通过总线、信号线或电路板与外围电子设备接口4013相连。
具体地，外围电子设备包括但不限于射频电路4014、触摸显示屏4015和电源4016。外围电子设备接口4013可以被用于将输入/输出(Input/Output，I/O)相关的至少一个外围电子设备连接到处理器4011和存储器4012。在一些实施例中，处理器4011、存储器4012和外围电子设备接口4013被集成在同一芯片或电路板上；在一些其他实施例中，处理器4011、存储器4012和外围电子设备接口4013中的任意一个或两个可以在单独的芯片或电路板上实现，本公开实施例对此不进行限定。
射频电路4014用于接收和发射射频(Radio Frequency，RF)信号，也称电磁信号。射频电路4014通过电磁信号与通信网络以及其他通信电子设备进行通信。射频电路4014将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路4014包括天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等。射频电路4014可以通过至少一种无线通信协议来与其它电子设备进行通信。该无线通信协议包括但不限于城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或无线保真(Wireless Fidelity，WiFi)网络。在一些实施例中，射频电路4014还可以包括近距离无线通信(Near Field Communication，NFC)有关的电路。
触摸显示屏4015用于显示用户界面(User Interface，UI)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当触摸显示屏4015是触摸显示屏时，触摸显示屏4015还具有采集在触摸显示屏4015的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器4011进行处理。此时，触摸显示屏4015还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，触摸显示屏4015可以为一个，设置在电子设备401的前面板；在另一些实施例中，触摸显示屏4015可以为至少两个，分别设置在电子设备401的不同表面或呈折叠设计；在又一些实施例中，触摸显示屏4015可以是柔性显示屏，设置在电子设备401的弯曲表面上或折叠面上。甚至，触摸显示屏4015还可以设置成非矩形的不规则图形，也即异形屏。触摸显示屏4015可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等材质制备。
本领域技术人员可以理解，图11中示出的结构并不构成对电子设备401的限定，可 以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
在本实施例中，电子设备401还包括有一个或者一个以上的程序，这一个或者一个以上程序存储于存储器4012中，且经配置以由一个或者一个以上处理器4011执行，一个或者一个以上程序包括用于进行本公开实施例提供的上述电子设备执行的车载操作系统中的任务同步、通信和驱动方法，以及BEOS调试方法的指令。
基于前述实施例，本公开实施例提供一种服务器的结构框图。请参考图12所示，该服务器402可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，CPU)4021(例如，一个或一个以上处理器)和存储器4022，一个或一个以上存储应用程序4023或数据4024的存储介质4025(例如一个或一个以上海量存储电子设备)。其中，存储器4022和存储介质4025可以是短暂存储或持久存储。存储在存储介质4025的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机系统中的一系列指令进行操作。中央处理器4021可以设置为与存储介质4025通信，在服务器402上执行存储介质4025中的一系列指令操作。
服务器402还可以包括一个或一个以上电源4026，一个或一个以上有线或无线网络接口4027，一个或一个以上输入输出接口4028，和/或，一个或一个以上操作系统4029，例如BEOS、Windows Server TM，Mac OS XTM，Unix TM,Linux TM，FreeBSDTM等等。
作为另一方面，本公开实施例提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例车载操作系统中的任务同步、通信和驱动方法，以及BEOS调试方法中的任意一种实施方式。
作为再一方面，本公开实施例提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例车载操作系统中的任务同步、通信和驱动方法，以及BEOS调试方法中的任意一种实施方式。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本公开所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者 全部模块来实现本实施例方案的效果。
另外，在本公开各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。而集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。
基于这样的理解，本公开的技术方案对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机电子设备(可以是个人计算机，服务器，或者网络电子设备等)执行本公开各个实施例信息上报方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
需要说明的是，以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参考前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本公开各实施例技术方案的精神和范围。

Claims (13)

  1. 一种车载操作系统，其特征在于，包括由下而上依次设置的硬件层、软件层和应用层；其中，
    所述硬件层包括至少一个控制器硬件，每个所述控制器硬件包括一个处理器；
    所述软件层包括BEOS操作系统和BEOS驱动；其中，所述BEOS操作系统用于管理和控制计算机系统的硬件和软件资源，所述BEOS驱动用于完成硬件层与软件层之间数据传送；
    所述应用层包括多个应用程序，多个所述应用程序与所述BEOS操作系统通过操作系统接口连接，每个所述应用程序用于提供车载相关的应用。
  2. 根据权利要求1所述的车载操作系统，其特征在于，
    所述BEOS操作系统包括由上而下依次设置的任务层、中间协议栈层和OS内核层；
    所述BEOS驱动至少包括如下一种驱动：串口驱动、CAN驱动、SPI驱动、Flash驱动、I2C驱动和RTC驱动。
  3. 根据权利要求2所述的车载操作系统，其特征在于，所述中间协议栈层包括至少如下一项：网络管理模块、CAN服务模块和数据持久化管理模块。
  4. 根据权利要求2或3所述的车载操作系统，其特征在于，所述中间协议栈层还包括至少如下一项：文件系统模块、TCP/IP协议模块、蓝牙协议栈模块、信号管理模块。
  5. 根据权利要求2-4中任一项所述的车载操作系统，其特征在于，所述OS内核层包括至少如下一项：任务管理模块、任务通信模块、内存管理模块、内存运行库模块、定时器管理模块、同步管理模块、中断管理模块。
  6. 根据权利要求2-5中任一项所述的车载操作系统，其特征在于，所述任务层包括工作任务模块和系统监控任务模块；其中，所述工作任务模块包括至少一个主任务单元，每个所述主任务单元与至少一个子任务单元通信连接。
  7. 根据权利要求6所述的车载操作系统，其特征在于，所述主任务单元用于提供资源集中管理和子任务单元管理；其中，
    所述资源集中管理包括至少如下一项内容：定时器、消息队列、信号量、等待列表、硬件资源的申请和释放；
    所述子任务单元管理包括至少如下一项内容：子任务创建、子任务删除、子任务状态控制、子任务状态监控。
  8. 根据权利要求6或7所述的车载操作系统，其特征在于，所述工作任务模块中任务通信方法包括：
    主任务通过CreateMQ()创建子任务使用的消息队列；
    至少一个待发送消息的子任务分别通过SendMsg()将消息数据传输到所述消息队列中；
    至少一个待接收消息的子任务通过ReceiveMsg()从所述消息列队中接收消息数据。
  9. 一种BEOS调试系统，其特征在于，所述BEOS调试系统运行于PC端，用于对权利要求1-8中任一项所述的车载操作系统进行开发、验证、调试、维护。
  10. 根据权利要求9所述的BEOS调试系统，其特征在于，所述BEOS调试系统包括：
    通信协议处理模块，用于提供BEOS调试系统与BEOS操作系统通信数据处理；
    源代码处理模块，用于提供源代码数据结构解析、源代码显示、源代码定位功能；
    调试元素解析模块，用于提供需要调试的变量显示功能；
    用户操作界面模块，用于提供用户操作界面。
  11. 一种BEOS调试方法，其特征在于，包括：
    BEOS调试系统向车载操作系统发送调试指令；
    所述车载操作系统根据所述调试指令对待调试对象进行调试；
    所述待调试对象根据所述调试指令运行，并将运行结果反馈给所述BEOS调试系统；
    所述BEOS调试系统根据所述待调试对象的运行结果确定所述待调试对象的性能。
  12. 一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如权利要求8所述的任务通信方法的步骤，以及实现如权利要求11所述的BEOS调试方法的步骤。
  13. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求8所述的任务通信方法的步骤，以及实现如权利要求11所述的BEOS调试方法的步骤。
PCT/CN2022/142712 2021-12-30 2022-12-28 车载操作系统、调试系统及方法、电子设备及存储介质 WO2023125635A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020247006082A KR20240033083A (ko) 2021-12-30 2022-12-28 차량-장착 운영 체제, 디버깅 시스템 및 방법, 전자 디바이스 및 저장 매체

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111663812.0A CN116414589A (zh) 2021-12-30 2021-12-30 车载操作系统、调试系统及方法、电子设备及存储介质
CN202111663812.0 2021-12-30

Publications (1)

Publication Number Publication Date
WO2023125635A1 true WO2023125635A1 (zh) 2023-07-06

Family

ID=86997991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/142712 WO2023125635A1 (zh) 2021-12-30 2022-12-28 车载操作系统、调试系统及方法、电子设备及存储介质

Country Status (3)

Country Link
KR (1) KR20240033083A (zh)
CN (1) CN116414589A (zh)
WO (1) WO2023125635A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080201453A1 (en) * 2007-02-19 2008-08-21 Ondeego, Inc. Methods and system to create applications and distribute applications to a remote device
CN102539955A (zh) * 2012-03-22 2012-07-04 深圳市金凯博自动化测试有限公司 车载多媒体的自动化测试系统
CN103365236A (zh) * 2013-06-24 2013-10-23 成都市晶林科技有限公司 便于调试的车载监控终端
CN112737893A (zh) * 2020-12-31 2021-04-30 江西江铃集团新能源汽车有限公司 一种车载终端的网速调试方法、系统及可读存储介质
CN113821247A (zh) * 2020-06-19 2021-12-21 比亚迪股份有限公司 车载软件开发平台

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080201453A1 (en) * 2007-02-19 2008-08-21 Ondeego, Inc. Methods and system to create applications and distribute applications to a remote device
CN102539955A (zh) * 2012-03-22 2012-07-04 深圳市金凯博自动化测试有限公司 车载多媒体的自动化测试系统
CN103365236A (zh) * 2013-06-24 2013-10-23 成都市晶林科技有限公司 便于调试的车载监控终端
CN113821247A (zh) * 2020-06-19 2021-12-21 比亚迪股份有限公司 车载软件开发平台
CN112737893A (zh) * 2020-12-31 2021-04-30 江西江铃集团新能源汽车有限公司 一种车载终端的网速调试方法、系统及可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Learn about e-platform 3.0 and see BYD's product strategy Source: Public account "Yanzhi New Energy Vehicles", 51FUSA, 18 September 2021 (2021-09-18), XP093074561, Retrieved from the Internet <URL:https://www.51fusa.com/client/information/informationdetail/id/2060.html> [retrieved on 20230817] *

Also Published As

Publication number Publication date
KR20240033083A (ko) 2024-03-12
CN116414589A (zh) 2023-07-11

Similar Documents

Publication Publication Date Title
US9864627B2 (en) Power saving operating system for virtual environment
CN106933580B (zh) 一种嵌入式软件架构系统
CN103309792A (zh) 一种日志信息的控制方法及系统
CN104461970A (zh) Dma控制器、移动终端以及数据搬运方法
Zuepke et al. AUTOBEST: a united AUTOSAR-OS and ARINC 653 kernel
Reichenbach et al. Heterogeneous computing utilizing FPGAs: a new and flexible approach integrating dedicated hardware accelerators into common computing platforms
US20110173503A1 (en) Hardware enabled performance counters with support for operating system context switching
Gan Tradeoff analysis for dependable real-time embedded systems during the early design phases
Niedrist Deterministic architecture and middleware for domain control units and simplified integration process applied to ADAS
WO2023125635A1 (zh) 车载操作系统、调试系统及方法、电子设备及存储介质
US11243800B2 (en) Efficient virtual machine memory monitoring with hyper-threading
Kinnan et al. Porting applications to an ARINC 653 compliant IMA platform using VxWorks as an example
US10261817B2 (en) System on a chip and method for a controller supported virtual machine monitor
US10782764B2 (en) Techniques of emulating an ACPI controller on a service processor
Craveiro Integration of generic operating systems in partitioned architectures
US20180060097A1 (en) Hyper-threading based host-guest communication
CN117435310A (zh) 一种调度方法及电子设备
Gala Resource management for real-time and mixed-critical systems
Knorr Exploring Xen/KVM in prototyping an automotive use-case
Thompson et al. Introducing the .NET Micro Framework
Lopez Advanced integration techniques for highly reliable dual-os embedded systems
Ottaviano et al. RPUGuard: a Building Block for Next-Generation MPSoCs Hypervisors toward Mixed-Criticality Systems
Sinkkonen Asymmetric multiprocessing of Linux and hard real-time systems
Schönwälder Operating Systems’ 2020
Beningo Embedded Software Architecture Design

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22914887

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20247006082

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1020247006082

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2022914887

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022914887

Country of ref document: EP

Effective date: 20240326