Software package analysis method and device and vehicle

Abstract

The invention discloses a software package analysis method and device and a vehicle, which can reduce the application development difficulty, improve the application deployment efficiency and save the labor cost. In the method, a first object obtains a software package. And the first object analyzes the software package to obtain the directory. And the first object reads the application data of the first object from the software package according to the directory, wherein the first object is any one of the at least one object. On the basis of the software package format in the application, any object can read the corresponding application data from the software package according to the directory after obtaining the software package, so that the process, standardization and automatic deployment of various applications in different processors or domains can be realized; the application development difficulty can be reduced, the application deployment efficiency is improved, and the labor cost is saved.

Description

Software package parsing method, device and vehicle Technical Field

[0001] The present application relates to the field of smart vehicle technology, and in particular to a software package parsing method, device, and vehicle. Background Art

[0002] With the development of intelligent driving, there is a consensus on the evolution of automotive electronic architecture, moving from distributed to centralized. The fundamental concept of a centralized architecture is to centrally process functions across various domains, domain groups, or the entire vehicle. This approach addresses the issue of excessive electronic control units (ECUs) in distributed automotive architectures. This user-centric centralized architecture offers advantages such as hardware sharing, layered decoupling, and continuous upgrades.

[0003] In a centralized electronic architecture, the on-board computing platform connects various sensors (such as lidar, cameras, millimeter-wave radar, etc.), peripheral devices (such as touch screens, microphones, speakers, etc.), control systems (such as steering units, throttles, etc.), user interfaces (such as human-machine interfaces (HMI)), and other components to process the data generated by these components. Various applications (hereinafter referred to as applications) need to access or control these components through the on-board computing platform. Different application operating environments have different functional safety requirements, and the on-board computing platform, as a provider of basic capabilities, needs to provide customized capabilities for the functional safety requirements of different applications. For example, applications with different functional safety requirements can be deployed in operating environments with different security levels to adapt to the functional safety requirements of different applications.

[0004] When developing and deploying applications on an in-vehicle computing platform, existing technologies rely on manual labor to adapt and deploy applications one by one, which results in problems such as high difficulty in application development, low efficiency in application deployment, and high labor costs.

[0005] Summary of the Invention

[0006] The present application provides a software package parsing method, device, and vehicle, which can reduce the difficulty of application development, improve application deployment efficiency, and save labor costs.

[0007] In a first aspect, a software package parsing method is provided, comprising: obtaining, by a first object, a software package, wherein the software package includes a directory and application data of at least one object, the directory indicating a location of the application data of each of the at least one object in the software package, the application data including an application set corresponding to the at least one object, configuration information related to the application set, and software data corresponding to each application in the application set, wherein the object includes a processor or a domain; parsing the software package by the first object to obtain a directory; and reading, by the first object, the application data of the first object from the software package based on the directory, where the first object is any one of the at least one object.

[0008] The application set may be an application list, a file including application information, or data in other formats.

[0009] Embodiments of the present application provide a software package format that includes a directory and application data for at least one object. When developing and deploying applications, application providers can package the application data according to this format to form a software package. After obtaining the software package, any object can read its corresponding application data from the package based on the directory. This streamlines, standardizes, and automatically deploys various applications across different processors or domains on a computing platform, reducing application development complexity, improving application deployment efficiency, and saving labor costs.

[0010] In one possible design, the directory includes a first-category directory and a second-category directory, the first-category directory includes indication information of the second-category directory pointing to the first object, and the second-category directory includes application data.

[0011] Through this design method, the first object can find the second-category directory of the first object according to the instruction information in the first-category directory, and then obtain the application data of the first object according to the second-category directory of the first object, thereby improving the efficiency of obtaining application data and thus improving the deployment efficiency of the application.

[0012] In a possible design, before the first object reads the application data of the first object from the software package according to the directory, the first object also writes instruction information into the first type directory according to the configuration of the first object.

[0013] This design eliminates the need for a separate first-category directory for each object in the software package. Instead, each object populates the first-category directory based on its own configuration after receiving the software package, effectively reducing data redundancy within the software package. Furthermore, application providers and applications no longer need to know which objects their applications should be installed on, simplifying application development.

[0014] In one possible design, the second-category directory also includes indication information of the third-category directory of each object in at least one object, and the third-category directory of each object points to the software data of each object.

[0015] Through this design method, the first object can find the third directory of the first object according to the indication information in the second directory, and then obtain the software data of the first object according to the third directory of the first object, thereby improving the efficiency of obtaining software data and thus improving the deployment efficiency of the application.

[0016] In one possible design, at least one object is multiple, and at least two of the multiple objects have the same third-category directory. In other words, at least two objects in the second-category directory have the same indication information of the third-category directory.

[0017] With this design approach, the software data placed in the software package can be used by multiple objects, effectively reducing data redundancy caused by distributing different software packages to different objects.

[0018] In one possible design, the indication information is a link or a pointer.

[0019] Of course, this is only an example and not a limitation. In actual applications, the indication information may also be in other forms.

[0020] In a possible design, at least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.

[0021] Through this design approach, the software package can design different directories for domains with different security levels, which can simultaneously meet the development needs of multiple functional safety applications.

[0022] In one possible design, the software package includes an APP partition and a signature area, the directory is located in the APP partition, and the signature area is used to store the signature. Accordingly, the first object can also read the signature in the signature area and verify the integrity and security of the software package based on the signature.

[0023] With this design approach, the first object can install the application after confirming that the software package is complete and safe, thereby improving the reliability of application deployment.

[0024] In one possible design, the signature includes one or more of a platform signature, an application provider signature, and a user signature; the signature area also includes information indicating the type and / or size of the signature in the signature area.

[0025] Through this design approach, the efficiency and accuracy of the first object parsing software package can be improved.

[0026] In one possible design, the object includes a processor or a domain in a processor in an in-vehicle computing platform.

[0027] In other words, the technical solution of the embodiment of the present application can be applied to the development and deployment scenarios of applications on the vehicle computing platform. Through this design method, the vehicle computing platform can deploy various applications on different processors or different domains of the vehicle computing platform in a streamlined, standardized and automated manner, which can reduce the difficulty of application development on the vehicle computing platform, improve application deployment efficiency and save labor costs.

[0028] In a second aspect, a software package parsing device is provided, which includes modules, units, or technical means for executing the method described in the first aspect or any possible design of the first aspect.

[0029] Exemplarily, the device may include:

[0030] an acquisition module configured to acquire a software package, wherein the software package includes a directory and application data of at least one object, the directory indicating a location of the application data of each of the at least one object in the software package, the application data including an application set corresponding to the at least one object, configuration information related to the application set, and software data corresponding to each application in the application set, wherein the object includes a processor or a domain;

[0031] The processing module is configured to: parse the software package to obtain a directory; and read application data of a first object from the software package according to the directory, where the first object is any one of the at least one object.

[0032] In one possible design, the directory includes a first-category directory and a second-category directory, the first-category directory includes indication information of the second-category directory pointing to the first object, and the second-category directory includes application data.

[0033] In one possible design, the processing module is further configured to: before reading the application data of the first object from the software package according to the directory, write the instruction information into the first type directory according to the configuration of the first object.

[0034] In one possible design, the second-category directory also includes indication information of the third-category directory of each object in at least one object, and the third-category directory of each object points to the software data of each object.

[0035] In a possible design, there are multiple objects of at least one type, and the third category directories of at least two objects among the multiple objects are the same.

[0036] In a possible design, at least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.

[0037] In one possible design, the software package includes an APP partition and a signature area. The directory is located in the APP partition, and the signature area is used to store signatures. The processing module is also used to: read the signature in the signature area and verify the integrity and security of the software package based on the signature.

[0038] In one possible design, the signature includes one or more of a platform signature, an application provider signature, and a user signature; the signature area also includes information indicating the type and / or size of the signature in the signature area.

[0039] In one possible design, the object includes a processor or a domain in a processor in an in-vehicle computing platform.

[0040] In a third aspect, a processing device is provided, comprising: at least one processor and an interface circuit;

[0041] The interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device. The processor is used to implement the method described in the first aspect or any possible design of the first aspect through logic circuits or execution code instructions.

[0042] In a fourth aspect, a terminal device is provided, comprising the apparatus as described in the second aspect or any possible design of the second aspect.

[0043] Optionally, the terminal device is a vehicle-mounted terminal, a general-purpose computer or a server.

[0044] In a fifth aspect, a vehicle is provided, comprising the device as described in the second aspect or any possible design of the second aspect.

[0045] In a sixth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium is used to store instructions, and when the instructions are executed, the method described in the first aspect or any possible design of the first aspect is implemented.

[0046] In a seventh aspect, a computer program product is provided, wherein instructions are stored in the computer program product, which, when executed on a computer, enables the computer to execute the method described in the first aspect or any possible design of the first aspect.

[0047] The beneficial effects of the second to seventh aspects mentioned above can refer to the beneficial effects of the corresponding designs of the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application;

[0049] FIG2 is a schematic diagram of a vehicle 100 ;

[0050] FIG3 is a flowchart of a software package parsing method provided in an embodiment of the present application;

[0051] FIG4 is a schematic diagram of different objects reading application data from a software package;

[0052] FIG5 is a schematic diagram of a software package parsing device 500 provided in an embodiment of the present application;

[0053] FIG6 is a schematic diagram of another software package parsing device 600 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the previous and next associated objects are in an "or" relationship; in the formula of this application, the character " / " indicates that the previous and next associated objects are in a "division" relationship. "Including at least one of A, B and C" can mean: including A; including B; including C; including A and B; including A and C; including B and C; including A, B and C.

[0055] The technical solutions provided in the embodiments of the present application can be applied to application development and / or deployment scenarios of any centralized electronic architecture.

[0056] For example, referring to FIG1 , an application scenario diagram is provided for an embodiment of the present application. The scenario includes at least one developer's (or application provider's) device 200 and a vehicle 100. The vehicle 100 is equipped with an in-vehicle computing platform 110. Any developer's device 200 can deploy applications on the in-vehicle computing platform 110. The application deployment process, for example, is as follows: the developer's device 200 sends a software package to the in-vehicle computing platform 110. The in-vehicle computing platform 110 can parse the software package and obtain the application data provided by the developer's device 200, and then install the application based on the application data. The in-vehicle computing platform 110 can run the application to access and control various components of the vehicle.

[0057] As an example, see FIG2 , which is a schematic diagram of a vehicle 100 , including an onboard computing platform 110 , a sensor system 120 , a control system 130 , peripheral devices 140 , a power supply 150 , a user interface 160 , and the like. It should be noted that in other examples, vehicle 100 may include more, fewer, or different systems, and each system may include more, fewer, or different components. Furthermore, the illustrated systems and components may be combined or divided in any manner, and this application does not impose specific limitations thereon.

[0058] The sensor system 120 may include several sensors for sensing information about the environment in which the vehicle 100 is located. As shown in FIG2 , the sensors of the sensor system 120 include a global positioning system (GPS) 126, an inertial measurement unit (IMU) 125, a laser radar 122, a camera sensor 123, a millimeter wave radar 124, and an actuator 121 for modifying the position and / or orientation of the sensors. The millimeter wave radar 124 may use radio signals to sense targets within the surrounding environment of the vehicle 100. In some embodiments, in addition to sensing targets, the millimeter wave radar 124 may also be used to sense the speed and / or heading of the targets. The laser radar 122 may use lasers to sense targets in the environment in which the vehicle 100 is located. In some embodiments, the laser radar 122 may include one or more laser sources, a laser scanner, and one or more detectors, among other system components. The camera sensor 123 may be used to capture multiple images of the surrounding environment of the vehicle 100. The camera sensor 123 may be a still camera or a video camera.

[0059] The control system 130 is used to control the operation of the vehicle 100 and its components. The control system 130 may include various components, including a steering unit 136, a throttle 135, a brake unit 134, a sensor fusion unit 133, a computer vision system 132, a route control system 131, and an obstacle avoidance system 137. The steering unit 136 is operable to adjust the forward direction of the vehicle 100. For example, in one embodiment, it may be a steering wheel system. The throttle 135 is used to control the operating speed of the engine 114 and, in turn, the speed of the vehicle 100. The control system 130 may additionally or alternatively include other components in addition to the components shown in FIG. This application does not specifically limit this.

[0060] Peripheral device 140 can be configured to allow vehicle 100 to interact with external sensors, other vehicles, and / or users. To this end, peripheral device 140 may include, for example, a wireless communication system 144, a touch screen 143, a microphone 142, and / or a speaker 141. Peripheral device 140 may additionally or alternatively include other components in addition to those shown in FIG. This application does not impose any specific limitations on this.

[0061] Power source 150 may be configured to provide power to some or all of the components of vehicle 100 .

[0062] The vehicle-mounted computing platform 110 may be specifically implemented as a computer system with processing capabilities. For example, the vehicle-mounted computing platform 110 may include a mobile data center (MDC).

[0063] The onboard computing platform 110 may be configured to receive data from and control sensor system 120 , control system 130 , peripheral devices 140 , etc. The onboard computing platform 110 may also be configured to display a display that generates images on user interface 160 or receive input from user interface 160 .

[0064] Some or all functions of the vehicle 100 are controlled by an onboard computing platform 110. The onboard computing platform 110 may include at least one processor 161 that executes instructions 1631 stored in a non-transitory computer-readable medium such as a memory 163. The onboard computing platform 110 may also be a plurality of computing devices that control individual components or subsystems of the vehicle 100 in a distributed manner.

[0065] Optionally, the onboard computing platform 110 may further include a transceiver 162 for enabling communication between the onboard computing platform 110 and other components in the vehicle 100 and / or for enabling communication between the onboard computing platform 110 and other devices outside the vehicle 100 .

[0066] The processor 161 can be any processor, such as a system-on-chip (SoC), a central processing unit (CPU), an application-specific integrated circuit (ASIC), or other hardware-based dedicated processing device. Although FIG2 functionally illustrates a processor, memory, and other components, it should be understood by those skilled in the art that the processor and memory may actually include multiple processors and memories stored in the same physical housing, or the processor and memory may actually include multiple processors and memories that are not stored in the same physical housing. For example, the memory may be a hard drive or other storage medium located in a housing different from the onboard computing platform 110. Therefore, references to a processor or computer will be understood to include references to a collection of processors or memories that may or may not operate in parallel. Rather than using a single processor to perform the steps described herein, some components, such as the steering assembly and the deceleration assembly, may each have their own processor that performs only calculations related to the functionality of the particular component.

[0067] The processor 161 may have one or more domains. When the processor 161 includes multiple domains, the operating environments and data between different domains are isolated from each other. A domain is specifically an operating system, for example. For example, the processor 161 can run multiple different operating systems at the same time.

[0068] The onboard computing platform 110 may control functions of the vehicle 100 from input received from various subsystems (eg, the sensor system 120 and the control system 130 ) as well as from the user interface 160 .

[0069] Furthermore, the in-vehicle computing platform 110 controls the functions of the vehicle 100 by running applications. Each processor 161 or application in each domain can access and control various components through the in-vehicle computing platform 110 to implement the corresponding functions of the application, including but not limited to intelligent driving, reversing image, calling, audio, etc.

[0070] In practice, different applications have different functional safety requirements. As a provider of fundamental capabilities, in-vehicle computing platforms must offer customized capabilities for these applications. For example, applications with different functional safety requirements can be deployed in different security-level operating environments to meet these requirements. Relying solely on manual effort to adapt and deploy these applications individually can lead to challenges such as high application development difficulty, low deployment efficiency, and high labor costs.

[0071] In view of the above factors, a technical solution of an embodiment of the present application is provided, in which a software package format is designed that is decoupled from the on-board computing platform application, so that the on-board computing platform can deploy various applications on different processors or different domains in a streamlined, standardized and automated manner, which can reduce the difficulty of application development, improve application deployment efficiency and save labor costs.

[0072] It should be noted that Figures 1 and 2 are only examples, and the technical solutions provided in the embodiments of the present application can also be applied to devices of other centralized electronic architectures. For ease of description, this article mainly uses the scenarios shown in Figures 1 and 2 as examples to describe the embodiments of the present application in detail.

[0073] 3 , which is a flowchart of a software package parsing method provided in an embodiment of the present application, the method includes steps S301 - S303 .

[0074] S301: A first object obtains a software package.

[0075] In the embodiments of this application, an object includes a processor, a domain, or other entity capable of parsing a software package, but this application does not impose any limitation. The first object is any one of at least one object in a carrier, for example, a processor or a domain on a processor. The carrier can be any device or platform on which software needs to be installed.

[0076] It is understood that when the first object is a domain on a processor, the first object can be identified by both the processor identifier and the domain identifier, or by the domain identifier alone, and this application does not impose any restrictions. For example, different processors have different processor identifiers, but domains on different processors can reuse the same domain identifier, so it is necessary to use the processor identifier + domain identifier to distinguish domains on different processors; for example, if domains on different processors cannot reuse the same domain identifier, then the domain identifier alone can be used to distinguish domains on different processors and to distinguish different domains on the same processor.

[0077] In one possible design, the object includes a processor or a domain in a processor in an in-vehicle computing platform. For example, the first object is a SoC on the in-vehicle computing platform, or the first object is an operating system on a SoC on the in-vehicle computing platform.

[0078] Furthermore, the first object obtains the software package, which can be specifically the vehicle-mounted computing platform receiving the software package from the application provider's server through a communication interface (such as a vehicle-mounted box (T-Box)), or the vehicle-mounted computing platform receiving the software package input by the user from the user interface, etc., which is not limited in this application.

[0079] Typically, the vehicle computing platform provider can install the platform basic software and user software packages in a fixed partition when the vehicle computing platform leaves the factory, and the software packages on the vehicle computing platform can be updated during the vehicle over-the-air (OTA) process. The software packages in the embodiments of this application can be software packages installed when the vehicle computing platform leaves the factory, or software packages upgraded by the vehicle during the OTA process, and this application does not impose any restrictions.

[0080] In a possible design, at least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.

[0081] Among them, the security level of the domain can represent the functional safety capabilities that the domain can provide. For example, the higher the security level of the domain, the higher the functional safety capabilities of the domain, and it is suitable for deploying applications with high functional safety requirements.

[0082] Functional safety can be understood as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E / E systems.

[0083] The higher the functional safety capability provided by a domain, the lower the risk of danger caused by abnormal functional performance of the electronic / electrical system when the application runs in the domain, or the lower the degree of danger caused by abnormal functional performance of the electronic / electrical system.

[0084] In a specific example, the safety level can be the automotive safety integrity level (ASIL) defined by the International Organization for Standardization (ISO) 26262, which includes four levels: ASIL-A, ASIL-B, ASIL-C, and ASIL D. ASIL-A is the lowest safety integrity level, which can minimize the unreasonable risk caused by hazards caused by abnormal functional performance of automotive electronic / electrical systems (which can represent the lowest functional safety capability); ASIL-D is the highest safety integrity level, which can minimize the unreasonable risk caused by hazards caused by abnormal functional performance of automotive electronic / electrical systems (which can represent the highest functional safety capability).

[0085] The functional safety requirements of an application (or functional safety requirements) can be understood as the requirements for the functional safety capabilities of the application's operating environment when it is deployed.

[0086] Generally speaking, the higher the functional safety requirements of an application, the lower the unreasonable risk caused by the dangers caused by abnormal functional performance of the electronic / electrical system, and the higher the functional safety capability requirements of the domain, and the application needs to be deployed in an operating environment with a higher security level.

[0087] For example, the domain is the upper operating system of the vehicle computing platform. The operating system can be divided into different domains according to the corresponding security level of each operating system, such as the secure executable environment (SEA) and the general executable environment (GEA). Among them, SEA is used to provide an operating environment with high functional safety capabilities, such as an ASIL-B operating environment, which is mainly used to deploy applications with high computing power requirements and high safety function requirements. GEA is used to provide an operating environment with low functional safety capabilities, such as an ASIL-A operating environment, which is mainly used to deploy applications with low computing power requirements and low safety function requirements.

[0088] The division of the SEA domain and the GEA domain can facilitate application providers to deploy applications according to the functional safety requirements of the applications, and can improve user experience and vehicle performance.

[0089] It should be understood that the division of the SEA domain and the GEA domain here is only an example and not a limitation. In actual applications, there may be other types of domain divisions, and this application does not impose any restrictions.

[0090] The software package includes application data of at least one object.

[0091] Application data includes but is not limited to the following three types:

[0092] (1) an application set corresponding to at least one object;

[0093] An application set is used to indicate the installation data of the applications in a software package. For example, an application set includes at least one application identifier, such as the application name (e.g., test_app, demo_app, etc.) or the application ID. Applications can include applications automatically launched by the Execution Management (EM), applications manually launched by the EM, or applications launched by other means, etc., and this application does not impose any restrictions.

[0094] In some possible implementations, an application may also be referred to as a process. The application set may be an application list, a file including application information, or data in other formats.

[0095] (2) Software data corresponding to the application;

[0096] The software data corresponding to an application is a type of application installation data, mainly referring to the application's corresponding executable files (bin) and public libraries (lib). Executable files include but are not limited to executable files used when the application is started, used, or manually debugged.

[0097] (3) Configuration information related to the application set;

[0098] The configuration information related to the application set may include configuration information corresponding to each application in the application set. The configuration information corresponding to each application is a type of installation data of the application.

[0099] For example, the configuration information corresponding to each application includes but is not limited to one or more of the following: an application configuration file (conf), an application startup script (script), other application files (etc), and the like.

[0100] It is understandable that in some implementations, the same configuration information may correspond to multiple different applications.

[0101] The software package further includes a directory, which indicates the location of application data of each object in the at least one object in the software package.

[0102] The location of the application data of each object in the software package includes, for example, a storage path of the software data and a storage path of the configuration information.

[0103] In one possible design, the directory includes a first-category directory and a second-category directory. The first-category directory includes information pointing to the second-category directory of the first object. The second-category directory includes application data. It is understood that the application data here can be partial or complete application data, without limitation. For example, the second-category directory includes at least an application collection and configuration information related to the application collection. This design improves the efficiency of object search for application data.

[0104] Optionally, the indication information is a link, a pointer or other types of indication information.

[0105] Optionally, the initial value of the first-category directory is empty or 0. Before the first object reads the application data of the first object from the software package according to the directory, the first object first writes the indication information into the first-category directory according to the configuration of the first object. Then, in the subsequent process of reading the application data of the first object from the software package, the second-category directory corresponding to the first object can be found according to the indication information in the first-category directory.

[0106] The configuration of the first object may specifically be an identifier of the first object, such as a processor identifier, a domain identifier, or a processor identifier+domain identifier.

[0107] In one possible design, an in-vehicle computing platform includes multiple SoCs and a microcontroller unit (MCU). Each SoC is connected to the MCU. The MCU can transmit a unique identifier to each SoC as its processor ID. Each SoC can then identify the software package based on the received identifier and determine its corresponding application data from the package. Furthermore, if the SoC contains multiple domains, each domain can also determine its corresponding application data from the software package based on its own domain identifier.

[0108] For ease of understanding, this example assumes that at least one object is four objects: the GEA domain in SoC 0, the SEA domain in SoC 0, the GEA domain in SoC 1, and the SEA domain in SoC 1. The software package contains two first-category directories: gea and sea; and four second-category directories: gea_a, gea_b, sea_a, and sea_b. Table 1 shows an example of a possible directory format.

[0109] Table 1

[0110]

[0111] In a possible design, the second type of directory also includes software data of each object in the at least one object. Still taking the above four objects as an example, Table 2 is an example of another possible directory format.

[0112] Table 2

[0113]

[0114] In an alternative design, the second-type directory also includes indication information of the third-type directory of each object in the at least one object, and the third-type directory of each object points to the software data of each object.

[0115] Optionally, the indication information may be a link or a pointer. Of course, this is merely an example and not a limitation, and in actual applications, the indication information may also be in other forms.

[0116] Still taking the above four objects as an example, Table 3 is an example of another possible directory format.

[0117] Table 3

[0118]

[0119] In one possible example, at least one object has multiple objects. The third-category directories of at least two of the multiple objects are identical, or in other words, the third-category directories of at least two of the second-category directories have identical indicative information. In this way, the software data stored in the software package can be used by multiple objects, effectively reducing data redundancy caused by distributing different software packages to different objects.

[0120] It should be noted that the directory formats listed in Tables 1, 2, and 3 above are examples and not limitations. In actual applications, the directories can be flexibly expanded based on the specific conditions of the objects on the vehicle computing platform. For example, if there are three SoCs on the vehicle computing platform, the second directory type can be expanded to include a gea_c directory and a sea_c directory, and so on.

[0121] In a possible design, at least some subdirectories in the third category directory may be identical to at least some subdirectories in the second category directory, but the same data is only stored in the third category directory or the second category directory.

[0122] For example, there is a subdirectory A in both the third and second directory categories, but the subdirectory A in the second directory contains a link to the subdirectory A in the third directory, and the subdirectory A in the third directory points to the software data.

[0123] For example, subdirectory B exists in both the third and second directory categories, but subdirectory B in the second directory category stores configuration information, while subdirectory B in the third directory category is empty.

[0124] For easier understanding, a detailed example is given here, as shown in Table 4.

[0125] Table 4

[0126]

[0127]

[0128]

[0129] Table 5 is an explanation of each sub-directory in Table 4:

[0130] Table 5

[0131]

[0132]

[0133] As can be seen from Table 4, the directory structure of the third type of directory (such as entity_gea) is the same as that of the second type of directory (such as gea_a or gea_b), but there are differences between entity_gea and gea_a or gea_b: the bin directory in gea_a or gea_b contains links to the bin directory under entity_gea (not directly pointing to the executable file), such as ".. / .. / .. / entity_gea / runtime_service / demo_app_1 / bin"; the lib directory in gea_a or gea_b contains links to the lib directory under entity_gea (not directly pointing to the public library), such as ".. / .. / entity_gea / bin". The bin directory and lib in entity_gea are different. The directories actually point to executable files and public libraries. The executable file pointed to by the bin directory in entity_gea is the combination of the executable files corresponding to gea_a and the executable files corresponding to gea_b. The executable file pointed to by the lib directory in entity_gea is the combination of the public libraries corresponding to gea_a and gea_b. For example, both gea_a and gea_b have demo_app_1, but entity_gea only stores one copy of the data for demo_app_1. The bin directory of demo_app_1 in gea_a and the bin directory of demo_app_1 in gea_b point to the same location in entity_gea, namely "entity_gea / runtime_service / demo_app_1 / bin".

[0134] It should be noted that the link under any bin in gea_a or gea_b can point to the bin with the same relative position in entity_gea (such as the bin under test_app under manual_service in gea_a points to the bin under test_app under manual_service in entity_gea), or it can point to the bin in other locations (such as the bin under test_app under manual_service in gea_a can also point to the bin under entity_gea). This application does not impose any restrictions.

[0135] The directory structure given in Table 4 is only an example and not a limitation.

[0136] This design can make the directory structure of the software package more neat and simple, and reduce redundant data.

[0137] It can be understood that the directory structures listed above are all based on an example of at least one object being multiple objects. In actual applications, when the in-vehicle computing platform is a single-processor single-domain case, the directory structure can be further simplified.

[0138] For example, see Table 6, which is a schematic diagram of a single-domain directory structure. All original files in a single-domain directory are placed under entity_gea, and gea_a and gea_b only have links to the corresponding files in the entity_gea directory.

[0139] Table 6

[0140]

[0141] S302: The first object parses the software package to obtain a directory.

[0142] For example, when the vehicle computing platform is started (including cold and hot boots), the SoC on the vehicle computing platform (specifically, a domain in the SoC, which may be the first domain started on the vehicle computing platform) performs a mount operation on the software package, then identifies the software package through a file system driver (such as an ext2 driver, an ext3 driver, an ext4 driver, etc.), and then reads the directory of the software package. When each domain on the SoC is started, it performs a first-category directory filling operation on the software package.

[0143] As you can understand, in common operating systems (such as Linux), all files are placed in a tree-like directory structure with the root directory as the root. After the first object obtains the software package, the package is not initially located in this tree-like directory structure. The first object performs the mounting action, which involves finding a location in the tree-like directory to establish a mount point and mount the package to this location. This allows subsequent domains in the SoC to access the package from this mount point and read the package's directory.

[0144] S303: The first object reads the application data of the first object from the software package according to the directory.

[0145] Still taking the four objects mentioned above as an example (i.e., the GEA domain in SoC 0, the SEA domain in SoC 0, the GEA domain in SoC 1, and the SEA domain in SoC 1, the first object can be any one of them), refer to Figure 4, which is a schematic diagram of each object reading application data from the software package. It can be understood that the GEA domain in SoC 0, the SEA domain in SoC 0, the GEA domain in SoC 1, and the SEA domain in SoC 1 correspond to different second-class directories (i.e., gea_a, sea_a, gea_b, sea_b). In Figure 4, in order to clearly show the difference between gea_a, sea_a, gea_b, and sea_b, the different configuration information in gea_a, sea_a, gea_b, and sea_b is represented by "differential configuration", such as conf, machine, etc. In addition, in Figure 4, the indication information pointing to the third-class directory in the second-class directory is all based on links as an example, that is, "relative path symbolic links", which are not actually limited to this.

[0146] After the GEA domain in SoC 0 obtains the software package, it writes the gea_a directive information into the gea directory based on its own configuration. After starting the software package installation, the GEA domain in SoC 0 locates the gea_a directory based on the gea_a directive information in the gea directory, reads the configuration information (such as conf and test_app) from the gea_a directory, and locates the software data (such as bin files and lib files) in the entity_gea directory based on the links in the gea_a directory. Finally, the application installation is completed based on all the acquired data.

[0147] After the SEA domain in SoC 0 obtains the software package, it can write the sea_a instructions in the sea directory according to its own configuration. After starting the software package installation, the SEA domain in SoC 0 finds the sea_a directory according to the sea_a instructions in the sea directory, reads the configuration information (such as conf and test_app) from the sea_a directory, and finds the software data (such as bin files and lib files) in the entity_sea directory according to the links in the sea_a directory. Finally, based on all the obtained data, the application installation is completed.

[0148] After obtaining the software package, the GEA domain in SoC 1 writes the gea_b directive information to the gea directory based on its own configuration. After starting the software package installation, the GEA domain in SoC 1 locates the gea_b directory based on the gea_b directive information in the gea directory, reads the configuration information (such as conf and test_app) from the gea_b directory, and locates the software data (such as bin files and lib files) in the entity_gea directory based on the links in the gea_b directory. Finally, the application installation is completed based on all the acquired data.

[0149] After the SEA domain in SoC 1 obtains the software package, it writes the instructions for sea_b in the sea directory based on its own configuration. After starting the software package installation, the GEA domain in SoC 1 locates the sea_b directory based on the instructions for sea_b in the sea directory, reads the configuration information (such as conf and test_app) from the sea_b directory, and locates the software data (such as bin files and lib files) in the entity_sea directory based on the links in the sea_b directory. Finally, it completes the application installation based on all the obtained data.

[0150] In the above solution, the software package format includes a directory and application data of at least one object. When developing and deploying applications, application providers can package application data according to the software package format to form a software package. After any object obtains the software package, it can read its corresponding application data from the software package according to the directory. In this way, the in-vehicle computing platform can deploy various applications on different processors or domains in a streamlined, standardized, and automated manner, which can reduce the difficulty of application development, improve application deployment efficiency, and save labor costs. Moreover, when the in-vehicle computing platform is subsequently upgraded, this solution can also be used to upgrade some applications on the in-vehicle computing platform separately without affecting other applications. In addition, when the application data of a single application in the software package crashes abnormally, it will not affect the application data of other applications, nor will it affect the normal operation of the in-vehicle computing platform.

[0151] In one possible design, the software package includes an APP partition and a signature area. The above-mentioned directory and application data are located in the APP partition, and the signature area is used to store the signature. Accordingly, after obtaining the software package, the first object can also read the signature in the signature area and verify the integrity and security of the software package based on the signature. After confirming the integrity and security of the software package, the application is installed. For example, when the in-vehicle computing platform is started (including cold start and hot start), the processor first performs signature verification on the software package. After the signature verification passes, the software package is mounted and the directory of the software package is read.

[0152] In a specific example, the signature may include one or more of a platform signature, an application provider signature, and a user signature, and this application does not impose any restrictions. Taking the in-vehicle scenario as an example, the platform signature may be the signature of the in-vehicle computing platform, the application provider signature may be the signature of the merchant that needs to provide application services on the in-vehicle computing platform, and the user signature may be the signature of the vehicle owner.

[0153] Taking the user signature as an example, the user performs a hash calculation on the contents of the user's app partition to obtain a first hash digest, then signs the first hash digest and places the signed result in the user signature header of the digital signature additional field. When the in-vehicle computing platform loads the user's software package, it calculates the contents of the user's app partition again to obtain a second hash digest. The work certificate is used to obtain the signed first hash digest, and the first and second hash digests are compared. If they are identical, the integrity and security of the user software package are ensured.

[0154] This can improve the reliability of application deployment.

[0155] In one possible design, the signature area may further include information indicating the type and / or size of the signature in the signature area. For example, a secondary header is provided at the beginning of the signature area to indicate the type and / or size of the signature in the signature area.

[0156] In this way, the efficiency and accuracy of the first object parsing software package can be improved.

[0157] The method provided by the embodiment of the present application is described above in conjunction with the accompanying drawings, and the device provided by the embodiment of the present application is described below in conjunction with the accompanying drawings.

[0158] Based on the same technical concept, an embodiment of the present application provides a software package parsing device 500, which includes modules / units / means for executing the method executed by the first object in the above method embodiment. The modules / units / means can be implemented in software or hardware, or hardware can execute the corresponding software implementation.

[0159] Exemplarily, referring to FIG5 , a software package parsing device 500 may include:

[0160] an acquisition module 501 configured to acquire a software package, wherein the software package includes a directory and application data of at least one object, the directory indicating the location of the application data of each of the at least one object in the software package, the application data including an application set corresponding to the at least one object, configuration information related to the application set, and software data corresponding to each application in the application set, wherein the object includes a processor or a domain;

[0161] The processing module 502 is configured to: parse the software package to obtain a directory; and read application data of a first object from the software package according to the directory, where the first object is any one of the at least one object.

[0162] It should be understood that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0163] Based on the same technical concept, referring to FIG6 , an embodiment of the present application further provides a software package parsing device 600, which includes at least one processor 601 and an interface circuit 602; the interface circuit 602 is used to receive signals from other devices outside the device 600 and transmit them to the processor 601 or send signals from the processor 601 to other devices outside the device, and the processor 601 is used to implement the method executed by the first object in the above method embodiment through a logic circuit or executing code instructions.

[0164] It should be understood that the processors mentioned in the embodiments of the present application can be implemented by hardware or software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented by software, the processor can be a general-purpose processor that is implemented by reading software code stored in a memory.

[0165] Exemplarily, the processor may be a central processing unit (CPU), or other general-purpose processors, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0166] Based on the same technical concept, an embodiment of the present application also provides a computer-readable storage medium, including a program or instruction. When the program or instruction runs on a computer, the method executed by the first object in the above method embodiment is executed.

[0167] Based on the same technical concept, an embodiment of the present application further provides a computer program product comprising instructions. The computer program product stores instructions that, when executed on a computer, enable the method executed by the first object in the above method embodiment to be executed.

[0168] Based on the same technical concept, embodiments of the present application also provide a terminal device including the aforementioned software package parsing apparatus. The terminal device can be a vehicle, drone, helicopter, airplane, ship, intelligent transportation equipment, or smart home device. Embodiments of the present application do not limit the specific form of the terminal device.

[0169] It should be understood that the memory mentioned in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0170] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) can be integrated into the processor.

[0171] It should be noted that the memory described herein is intended to include, but not be limited to, these and any other suitable types of memory.

[0172] The above description is merely a partial embodiment of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the scope of protection of the present application. Thus, if such modifications and variations fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations.

Claims

1. A software package parsing method, characterized in that: include: The first object acquires a software package, wherein the software package includes a directory and application data of at least one object, the directory indicates a location of the application data of each object in the at least one object in the software package, the application data includes an application set corresponding to the at least one object, configuration information related to the application set, and software data corresponding to each application in the application set, and the object includes a processor or a domain; The first object parses the software package to obtain the directory; The first object reads application data of the first object from the software package according to the directory, where the first object is any one of the at least one object.

2. The method according to claim 1, wherein The directory includes a first-type directory and a second-type directory, the first-type directory includes indication information of the second-type directory pointing to the first object, and the second-type directory includes the application data.

3. The method according to claim 2, wherein Before the first object reads the application data of the first object from the software package according to the directory, the method further includes: The first object writes the instruction information into the first type directory according to the configuration of the first object.

4. The method according to claim 2 or 3, wherein: The second-type directory further includes indication information of a third-type directory of each object in the at least one object, and the third-type directory of each object points to software data of each object.

5. The method according to claim 4, wherein There are multiple objects, and at least two of the multiple objects have the same third category directory.

6. The method according to any one of claims 1 to 5, wherein: The at least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.

7. The method according to any one of claims 1 to 6, wherein: The software package includes an application APP partition and a signature area, the directory is located in the APP partition, and the signature area is used to store signatures; The method further comprises: The first object reads the signature in the signature area and verifies the integrity and security of the software package according to the signature.

8. The method according to claim 7, wherein The signature includes one or more of a platform signature, an application provider signature, and a user signature; The signature region further includes information indicating the type and / or size of the signature in the signature region.

9. The method according to any one of claims 1 to 8, wherein The object includes a processor or a domain in a processor in an in-vehicle computing platform.

10. A software package parsing device, characterized in that: include: an acquisition module, configured to acquire a software package, wherein the software package includes a directory and application data of at least one object, the directory indicating a location of the application data of each of the at least one object in the software package, the application data including an application set corresponding to the at least one object, configuration information related to the application set, and software data corresponding to each application in the application set, wherein the object includes a processor or a domain; Processing module for: Parsing the software package to obtain the directory; and The application data of the first object is read from the software package according to the directory, where the first object is any one of the at least one object.

11. The device according to claim 10, wherein The directory includes a first-type directory and a second-type directory, the first-type directory includes indication information of the second-type directory pointing to the first object, and the second-type directory includes the application data.

12. The device according to claim 11, wherein The processing module is further configured to: Before reading the application data of the first object from the software package according to the directory, the instruction information is written into the first type directory according to the configuration of the first object.

13. The device according to claim 11 or 12, characterized in that The second-type directory further includes indication information of a third-type directory of each object in the at least one object, and the third-type directory of each object points to software data of each object.

14. The device according to claim 13, wherein There are multiple objects, and at least two of the multiple objects have the same third category directory.

15. The device according to any one of claims 10 to 14, characterized in that The at least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.

16. The device according to any one of claims 10 to 15, characterized in that The software package includes an application APP partition and a signature area, the directory is located in the APP partition, and the signature area is used to store signatures; The processing module is further configured to: The signature in the signature area is read, and the integrity and security of the software package are verified based on the signature.

17. The device according to claim 16, wherein The signature includes one or more of a platform signature, an application provider signature, and a user signature; The signature region further includes information indicating the type and / or size of the signature in the signature region.

18. The device according to any one of claims 10 to 17, characterized in that The object includes a processor or a domain in a processor in an in-vehicle computing platform.

19. A processing device, characterized in that include: at least one processor and interface circuitry; The interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device. The processor implements the method according to any one of claims 1 to 9 through logic circuits or executing code instructions.

20. A terminal device, characterized in that: Comprising the device according to any one of claims 10-18.

21. A vehicle, characterized in that: Comprising the terminal device as claimed in claim 20.

22. A computer-readable storage medium, characterized in that The readable storage medium is used to store instructions, and when the instructions are executed, the method according to any one of claims 1 to 9 is implemented.

Images