WO2024130501A1 - 一种软件包解析方法、装置和车辆 - Google Patents

一种软件包解析方法、装置和车辆 Download PDF

Info

Publication number
WO2024130501A1
WO2024130501A1 PCT/CN2022/140103 CN2022140103W WO2024130501A1 WO 2024130501 A1 WO2024130501 A1 WO 2024130501A1 CN 2022140103 W CN2022140103 W CN 2022140103W WO 2024130501 A1 WO2024130501 A1 WO 2024130501A1
Authority
WO
WIPO (PCT)
Prior art keywords
directory
software package
application
signature
category
Prior art date
Application number
PCT/CN2022/140103
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 PCT/CN2022/140103 priority Critical patent/WO2024130501A1/zh
Publication of WO2024130501A1 publication Critical patent/WO2024130501A1/zh

Links

Images

Definitions

  • the present application relates to the field of smart vehicle technology, and in particular to a software package parsing method, device and vehicle.
  • the basic idea of centralized architecture is to centrally process the functions of each domain, domain group or vehicle level in the vehicle, which can solve the problem of too many electronic control units (ECU) in the distributed architecture of the vehicle.
  • ECU electronice control units
  • the user-centric centralized architecture has the advantages of hardware sharing, hierarchical decoupling, and continuous upgrading.
  • the on-board computing platform connects various sensors (such as lidar, cameras, millimeter-wave radar, etc.), peripherals (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
  • 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.
  • the existing technology uses manpower to adapt and deploy applications one by one, which has problems such as high difficulty in application development, low efficiency in application deployment, and high labor costs.
  • 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.
  • a software package parsing method comprising: a 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, the object includes a processor or a domain; the first object parses the software package to obtain the directory; the first object reads the application data of the first object from the software package according to the directory, the first object being any one of the at least one object.
  • the application set may be an application list, a file including application information, or data in other formats.
  • the embodiment of the present application provides a software package format, which includes a directory and application data of at least one object.
  • the application provider can package the application data according to the software package format to form a software package.
  • any object can read its corresponding application data from the software package according to the directory.
  • 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
  • the second-category directory includes application data
  • the first object can find the second-category directory of the first object according to the indication 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 efficiency of application deployment.
  • the first object 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 the instruction information into the first type directory according to the configuration of the first object.
  • 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.
  • 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.
  • At least one object is multiple, and the third-category directories of at least two of the multiple objects are the same.
  • the indication information of the third-category directories of at least two of the second-category directories is the same.
  • the software data placed in the software package can be used by multiple objects, which can effectively reduce data redundancy caused by distributing different software packages to different objects.
  • the indication information is a link or a pointer.
  • the indication information may also be in other forms.
  • At least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.
  • 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.
  • the software package includes an APP partition and a signature area
  • the directory is located in the APP partition
  • 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.
  • the first object can install the application after confirming that the software package is complete and safe, thereby improving the reliability of application deployment.
  • 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.
  • the object includes a processor or a domain in a processor in an in-vehicle computing platform.
  • 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.
  • 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.
  • a software package parsing device which includes a module or unit or technical means for executing the method described in the first aspect or any possible design of the first aspect.
  • the device may 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 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 processing module is used 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.
  • 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
  • the second-category directory includes application data
  • the processing module is further used to: before reading the application data of the first object from the software package according to the directory, write the indication information into the first type directory according to the configuration of the first object.
  • 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.
  • the number of at least one object is multiple, and the third category directories of at least two objects among the multiple objects are the same.
  • At least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.
  • the software package includes an APP partition and a signature area
  • the directory is located in the APP partition
  • 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.
  • 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.
  • the object includes a processor or a domain in a processor in an in-vehicle computing platform.
  • a processing device comprising: at least one processor and an interface circuit;
  • 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.
  • a terminal device comprising the apparatus as described in the second aspect or any possible design of the second aspect.
  • the terminal device is a vehicle-mounted terminal, a general-purpose computer or a server.
  • a vehicle comprising the device as described in the second aspect or any possible design of the second 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.
  • a computer program product wherein instructions are stored in the computer program product, and when the computer program product is run on a computer, the computer executes the method as described in the first aspect or any possible design of the first aspect.
  • 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.
  • FIG1 is a schematic diagram of an application scenario provided by an embodiment of the present application.
  • FIG2 is a schematic diagram of a vehicle 100
  • FIG3 is a flow chart of a software package parsing method provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of different objects reading application data from a software package
  • FIG5 is a schematic diagram of a software package parsing device 500 provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of another software package parsing device 600 provided in an embodiment of the present application.
  • “at least one” means one or more, and “more than one” means two or more.
  • “And/or” describes the association relationship of associated objects, indicating that three relationships may exist.
  • 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.
  • the character “/” generally indicates that the previous and next associated objects are in an “or” relationship; in the formula of the present 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.
  • the scenario includes at least one device 200 of a developer (or application provider) and a vehicle 100, the vehicle 100 is equipped with an onboard computing platform 110, and any device 200 of a developer can deploy applications on the onboard computing platform 110.
  • the application deployment process is, for example: the developer's device 200 sends a software package to the onboard computing platform 110, the onboard computing platform 110 can parse the software package and then obtain the application data provided by the developer's device 200, and install the application based on the application data.
  • the onboard computing platform 110 can access and control various components of the vehicle by running the application.
  • FIG2 is a schematic diagram of a vehicle 100, including: an on-board computing platform 110, a sensor system 120, a control system 130, a peripheral device 140, a power supply 150, a user interface 160, etc.
  • vehicle 100 may include more, fewer, or different systems, and each system may include more, fewer, or different components.
  • the systems and components shown may be combined or divided in any manner, and this application does not specifically limit this.
  • the sensor system 120 may include several sensors for sensing information about the environment in which the vehicle 100 is located. As shown in FIG. 2 , 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 sensor.
  • 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 forward direction of the target.
  • the laser radar 122 may use lasers to sense targets in the environment in which the vehicle 100 is located.
  • the laser radar 122 may include one or more laser sources, a laser scanner, and one or more detectors, as well as 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.
  • 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.
  • it can be a steering wheel system.
  • the throttle 135 is used to control the operating speed of the engine 114 and thus control the speed of the vehicle 100.
  • the control system 130 may additionally or alternatively include other components in addition to the components shown in Figure 2. This application does not specifically limit this.
  • the peripheral device 140 may be configured to allow the vehicle 100 to interact with external sensors, other vehicles, and/or users.
  • the peripheral device 140 may include, for example, a wireless communication system 144, a touch screen 143, a microphone 142, and/or a speaker 141.
  • the peripheral device 140 may additionally or alternatively include other components in addition to the components shown in FIG. 2. This application does not specifically limit this.
  • Power source 150 may be configured to provide power to some or all of the components of vehicle 100 .
  • the vehicle-mounted computing platform 110 may be specifically implemented as a computer system with processing capabilities.
  • the vehicle-mounted computing platform 110 may include a mobile data center (MDC).
  • MDC mobile data center
  • the onboard computing platform 110 may be configured to receive data from and control sensor systems 120 , control systems 130 , peripheral devices 140 , etc.
  • the onboard computing platform 110 may also be configured to display a display that generates images on a user interface 160 , or to receive input from the user interface 160 .
  • 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.
  • the on-board computing platform 110 may further include a transceiver 162 for enabling communication between the on-board computing platform 110 and other components in the vehicle 100 and/or for enabling communication between the on-board computing platform 110 and other devices outside the vehicle 100 .
  • a transceiver 162 for enabling communication between the on-board computing platform 110 and other components in the vehicle 100 and/or for enabling communication between the on-board computing platform 110 and other devices outside the vehicle 100 .
  • 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 devices.
  • SoC system-on-chip
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • FIG. 2 functionally illustrates a processor, a memory, and other elements, it should be understood by those skilled in the art that the processor and the memory may actually include multiple processors and memories stored in the same physical housing, or the processor and the memory may actually include multiple processors and memories not stored in the same physical housing.
  • 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 a computer will be understood to include references to a collection of processors or memories that may or may not operate in parallel. Different from using a single processor to perform the steps described herein, some components such as a steering component and a deceleration component may each have their own processor, which only performs calculations
  • 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, and multiple different operating systems can be run on the processor 161 at the same time.
  • the onboard computing platform 110 may control functions of the vehicle 100 from various subsystems (eg, the sensor system 120 and the control system 130 ) as well as input received from the user interface 160 .
  • the vehicle computing platform 110 controls the functions of the vehicle 100, which can be realized by running applications.
  • Each processor 161 or the application in each domain can access and control each component through the vehicle computing platform 110 to realize the functions corresponding to the application, where the functions include but are not limited to intelligent driving, reversing image, call, audio, etc.
  • a technical solution of an embodiment of the present application 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 in 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.
  • Figures 1 and 2 are only examples, and the technical solution provided in the embodiment of the present application can also be applied to other centralized electronic architecture devices.
  • this article mainly uses the scenarios shown in Figures 1 and 2 as examples to describe the embodiment of the present application in detail.
  • FIG. 3 is a flowchart of a software package parsing method provided in an embodiment of the present application, the method includes steps S301 - S303 .
  • S301 A first object obtains a software package.
  • the object includes a processor or a domain or other subject capable of parsing a software package, which is not limited in the present application.
  • the first object is any one of at least one object in a carrier, for example, the first object is a processor, or a domain on a processor.
  • the carrier can be any device or platform on which software needs to be installed.
  • the first object 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 can be identified by the domain identifier alone, and this application does not impose any restrictions.
  • 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, domains on different processors cannot reuse the same domain identifier, so domains on different processors and different domains on the same processor can be distinguished by the domain identifier alone.
  • the object includes a processor or a domain in a processor in the vehicle computing platform.
  • the first object is a SoC on the vehicle computing platform, or the first object is an operating system of a SoC on the vehicle computing platform.
  • the first object obtains the software package, which may be specifically that the vehicle-mounted computing platform receives the software package from the server of the application provider through a communication interface (such as a vehicle-mounted box (T-Box)), or the vehicle-mounted computing platform receives the software package input by the user from the user interface, etc., which is not limited in this application.
  • a communication interface such as a vehicle-mounted box (T-Box)
  • T-Box vehicle-mounted box
  • the vehicle computing platform provider can uniformly install the platform basic software and user software package into a fixed partition when the vehicle computing platform leaves the factory, and can update the software package on the vehicle computing platform during the vehicle over-the-air (OTA) process.
  • the software package in the embodiment of the present application can be the software package installed when the vehicle computing platform leaves the factory, or it can be the software package upgraded by the vehicle during the OTA process, and this application does not limit it.
  • At least one object includes multiple domains, and different domains in the multiple domains correspond to different security levels.
  • the security level of the domain can characterize 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, which is suitable for deploying applications with high functional safety requirements.
  • Functional safety can be understood as: the absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.
  • 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).
  • the functional safety requirements of an application can be understood as the requirements for the functional safety capabilities of the application's operating environment when it is deployed.
  • 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).
  • SEA secure executable environment
  • GEA general executable environment
  • 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.
  • 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, which can improve user experience and vehicle performance.
  • the software package includes application data of at least one object.
  • the application data includes but is not limited to the following three types:
  • the application set is used to indicate the installation data of the applications in the software package.
  • the application set contains at least one application identifier, such as the name of the application (such as test_app, demo_app, etc.), or the number of the application, etc.
  • the application may include an application automatically pulled up by the Execution Management (EM), an application manually pulled up by the EM, or an application pulled up by other means, etc., and this application does not limit this.
  • EM Execution Management
  • an application may also be referred to as a process.
  • the above application set may be an application list, a file including application information, or data in other formats.
  • the software data corresponding to the application is a type of installation data of the application, mainly referring to the executable files (bin) and public libraries (lib) corresponding to the application, etc.
  • the executable files include but are not limited to the executable files used when the application is started, used, or manually debugged.
  • 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 one of the installation data of the application.
  • the configuration information corresponding to each application includes but is not limited to one or more of the following: a configuration file (conf) of the application, a startup script (script) of the application, other files (etc) of the application, and the like.
  • the same configuration information may correspond to multiple different applications.
  • the software package also includes a directory , which indicates the location of application data of each object in the at least one object in the software package.
  • 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.
  • the directory includes a first-class directory and a second-class directory, and the first-class directory includes indication information pointing to the second-class directory of the first object.
  • the second-class directory includes application data. It can be understood that the application data here can be part of the application data or all of the application data without limitation.
  • the second-class directory at least includes the application set and configuration information related to the application set.
  • the indication information is a link, a pointer or other types of indication information.
  • the initial value of the first-category directory is empty or 0.
  • the first object 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 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.
  • the configuration of the first object may specifically be an identifier of the first object, such as a processor identifier, a domain identifier, a processor identifier+domain identifier, and the like.
  • a vehicle computing platform has multiple SoCs and a microcontroller unit (MCU).
  • Each SoC is connected to the MCU.
  • the MCU can pass a unique identifier to each SoC as the processor identifier of the SoC.
  • Each SoC can identify the software package based on the received identifier and determine its corresponding application data from the software package.
  • each domain can also determine its corresponding application data from the software package based on its own domain identifier.
  • the four objects are: GEA domain in SoC 0, SEA domain in SoC 0, GEA domain in SoC 1, SEA domain in SoC 1.
  • the second type of directory also includes software data of each object in at least one object. Still taking the above four objects as an example, Table 2 is an example of another possible directory format.
  • 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.
  • the indication information may be a link or a pointer.
  • this is only an example and not a limitation, and the indication information may also be in other forms in actual applications.
  • Table 3 is an example of another possible directory format.
  • At least one object has a plurality of objects.
  • the third-category directories of at least two of the plurality of objects are the same, or in other words, the indication information of the third-category directories of at least two of the second-category directories are the same.
  • the software data placed in the software package can be used by multiple objects, which can effectively reduce data redundancy caused by distributing different software packages to different objects.
  • the directory formats listed in Tables 1, 2, and 3 above are only examples and not limitations.
  • the directories can be flexibly expanded according to the specific conditions of the objects on the vehicle computing platform. For example, when there are three SoCs on the vehicle computing platform, the second category directory can be expanded to include one more gea_c directory and one sea_c directory, and so on.
  • At least some subdirectories in the third category directory may be the same as at least some subdirectories in the second category directory. However, the same data is only stored in the third category directory or the second category directory.
  • subdirectory A in both the third and second directories there is a subdirectory A in both the third and second directories, but subdirectory A in the second directory stores a link to subdirectory A in the third directory, and subdirectory A in the third directory points to software data.
  • Table 5 is an explanation of each sub-directory in 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 are the ones that actually point to executable files and public libraries.
  • the executable file pointed to by the bin directory in entity_gea is the collection of the executable files corresponding to gea_a and gea_b.
  • the executable file pointed to by the lib directory in entity_gea is the collection of the public libraries corresponding to gea_a and gea_b.
  • both gea_a and gea_b have demo_app_1, and entity_gea only stores one copy of the data for demo_app_1.
  • the bin of demo_app_1 in gea_a and the bin of demo_app_1 in gea_b point to the same location in entity_gea, that is, "entity_gea/runtime_service/demo_app_1/bin".
  • 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), and this application does not impose any restrictions.
  • the directory structure given in Table 4 is only an example and not a limitation.
  • This design method can make the directory structure of the software package more neat and simple, and reduce redundant data.
  • the directory structures listed above are all based on examples of at least one object being multiple objects.
  • the directory structure can be further simplified.
  • Table 6 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 corresponding files in the entity_gea directory.
  • S302 The first object parses the software package to obtain a directory.
  • the SoC on the vehicle computing platform when the vehicle computing platform is started (including cold start and hot start), the SoC on the vehicle computing platform (specifically, it can be a domain in the SoC, and the domain can be the first domain started on the vehicle computing platform) performs a mount action on the software package, and 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.
  • a file system driver such as an ext2 driver, an ext3 driver, an ext4 driver, etc.
  • S303 The first object reads application data of the first object from the software package according to the directory.
  • FIG4 is a schematic diagram of each object reading application data from a 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, 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.
  • the indication information pointing to the third-class directory in the second-class directory is all taken as an example of a link, i.e., a "relative path symbolic link", which is not actually limited to this.
  • the GEA domain in SoC 0 After the GEA domain in SoC 0 obtains the software package, it can write the instruction information of gea_a in the gea directory according to its own configuration. After starting the software package installation, the GEA domain in SoC 0 finds the gea_a directory according to the instruction information of gea_a in the gea directory, reads the configuration information (such as conf, test_app, etc.) from the gea_a directory, and finds the software data (such as bin files and lib files) under the entity_gea directory according to the link in the gea_a directory, and finally completes the installation of the application based on all the obtained data.
  • the configuration information such as conf, test_app, etc.
  • the SEA domain in SoC 0 After the SEA domain in SoC 0 obtains the software package, it can write the sea_a instruction information 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 instruction information in the sea directory, reads the configuration information (such as conf, test_app, etc.) from the sea_a directory, and finds the software data (such as bin files and lib files) under the entity_sea directory according to the link in the sea_a directory, and finally completes the application installation based on all the acquired data.
  • the configuration information such as conf, test_app, etc.
  • the GEA domain in SoC 1 After the GEA domain in SoC 1 obtains the software package, it can write the instruction information of gea_b in the gea directory according to its own configuration. After starting the software package installation, the GEA domain in SoC 1 finds the gea_b directory according to the instruction information of gea_b in the gea directory, reads the configuration information (such as conf, test_app, etc.) from the gea_b directory, and finds the software data (such as bin files and lib files) under the entity_gea directory according to the link in the gea_b directory, and finally completes the installation of the application based on all the obtained data.
  • the configuration information such as conf, test_app, etc.
  • the SEA domain in SoC 1 After the SEA domain in SoC 1 obtains the software package, it can write the instruction information of sea_b in the sea directory according to its own configuration. After starting the software package installation, the GEA domain in SoC 1 finds the sea_b directory according to the instruction information of sea_b in the sea directory, reads the configuration information (such as conf, test_app, etc.) from the sea_b directory, and finds the software data (such as bin files and lib files) under the entity_sea directory according to the link in the sea_b directory, and finally completes the installation of the application based on all the obtained data.
  • the configuration information such as conf, test_app, etc.
  • the software package format includes a directory and application data of at least one object.
  • the application provider can package the application data in accordance with the software package format to form a software package.
  • any object can read its corresponding application data from the software package according to the directory.
  • the vehicle computing platform can deploy various applications in 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.
  • this solution can also be used to upgrade some applications on the vehicle computing platform separately without affecting other applications.
  • 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 vehicle computing platform.
  • 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.
  • 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.
  • 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.
  • the signature may include one or more of a platform signature, an application provider signature, a user signature, etc., which are not limited in this application.
  • the platform signature may be the signature of the vehicle-mounted computing platform
  • the application provider signature may be the signature of the merchant who needs to provide application services on the vehicle-mounted computing platform
  • the user signature may be the signature of the vehicle owner.
  • the user performs a hash calculation on the content in the user's APP partition to obtain the first hash digest, and signs the first hash digest.
  • the signed result is placed in the user signature header position in the digital signature additional field.
  • the in-vehicle computing platform loads the user software package, it will calculate the content in the user's APP partition again to obtain the second hash digest, and use the work certificate to obtain the signed first hash digest.
  • the first hash digest and the second hash digest are compared. If they are the same, the integrity and security of the user software package can be ensured.
  • the signature area may also include information for indicating the type and/or size of the signature in the signature area.
  • 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.
  • the embodiment of the present application provides a software package parsing device 500, which includes a module/unit/means for executing the method executed by the first object in the above method embodiment.
  • the module/unit/means can be implemented by software, or by hardware, or the corresponding software can be implemented by hardware.
  • the software package parsing device 500 may include:
  • 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 indicates a location of 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 processing module 502 is used 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.
  • 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 execution code instructions.
  • the processor mentioned in the embodiments of the present application can be implemented by hardware or by software.
  • the processor can be a logic circuit, an integrated circuit, etc.
  • the processor can be a general-purpose processor implemented by reading software code stored in a memory.
  • the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (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 the processor may also be any conventional processor, etc.
  • an embodiment of the present application also provides a computer-readable storage medium, including a program or instruction.
  • the program or instruction runs on a computer, the method executed by the first object in the above method embodiment is executed.
  • an embodiment of the present application also provides a computer program product including instructions.
  • the computer program product stores instructions, and when the computer program product is run on a computer, the method executed by the first object in the above method embodiment is executed.
  • the embodiment of the present application also provides a terminal device, including the above-mentioned software package parsing device.
  • the terminal device can be a vehicle, a drone, a helicopter, an airplane, a ship, an intelligent transportation device, or a smart home device.
  • the embodiment of the present application does not limit the specific form of the terminal device.
  • 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.
  • 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.
  • RAM synchronous RAM
  • SDRAM synchronous DRAM
  • DDR SDRAM double data rate SDRAM
  • ESDRAM enhanced SDRAM
  • SLDRAM synchronous link DRAM
  • DR RAM direct rambus RAM
  • 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.
  • memory described herein is intended to include, without being limited to, these and any other suitable types of memory.

Landscapes

  • Stored Programmes (AREA)

Abstract

本申请公开了一种软件包解析方法、装置和车辆，可以降低应用开发难度、提高应用部署效率、节省人力成本。该方法中，第一对象获取软件包。第一对象解析软件包，得到目录。第一对象根据目录从软件包中读取第一对象的应用数据，第一对象为至少一个对象中的任意一个。基于本申请中的软件包格式，任一对象在获取到该软件包后，都可以根据目录从软件包中读取自身对应的应用数据，如此可以实现各类应用在不同处理器或域中的流程化、规范化、自动化部署，可以降低应用开发难度、提高应用部署效率、节省人力成本。

Description

一种软件包解析方法、装置和车辆 技术领域
本申请涉及智能车技术领域，尤其涉及一种软件包解析方法、装置和车辆。
背景技术
随着智能驾驶的发展，在汽车电子架构的演进方向上，形成从分布式走向集中式的一致意见。其中，集中式架构的基本思想是集中处理车辆中各个域、域组或整车级别上的功能，能够解决汽车分布式架构中电子控制单元(electronic control unit，ECU)过多的问题。以用户为中心的集中式，具有硬件共享、分层解耦、持续升级等优点。
在集中式电子架构中，车载计算平台连接各类传感器(如激光雷达、摄像头、毫米波雷达等)、外围设备(如触摸屏、麦克风、扬声器等)、控制系统(如转向单元、油门等)、用户接口(如人机界面(human machine interface，HMI))等元件处理这些元件产生的数据。各类应用程序(以下简称应用)需要通过车载计算平台访问或控制这些元件。不同应用运行环境有着不同的功能安全需求，而车载计算平台作为基础能力的提供者，需要对不同应用的功能安全需求提供定制化的能力，例如，将不同功能安全需求的应用分别部署在不同安全级别的运行环境，以适配不同应用的功能安全需求。
现有技术在车载计算平台上开发和部署应用时，都是通过人力对应用一一进行适配并部署，存在应用开发难度高、应用部署效率低、人力成本高等问题。
发明内容
本申请提供一种软件包解析方法、装置和车辆，可以降低应用开发难度、提高应用部署效率、节省人力成本。
第一方面，提供一种软件包解析方法，包括：第一对象获取软件包，其中，软件包包括目录和至少一个对象的应用数据，目录指示至少一个对象中每个对象的应用数据在软件包中的位置，应用数据包括至少一个对象对应的应用集合、应用集合相关的配置信息，以及应用集合中每个应用对应的软件数据，对象包括处理器或域；第一对象解析软件包，得到目录；第一对象根据目录从软件包中读取第一对象的应用数据，第一对象为至少一个对象中的任意一个。
上述应用集合可以是应用列表、包括应用信息的文件或其他格式的数据。
本申请实施例提供了一种软件包格式，该软件包格式包括目录和至少一个对象的应用数据。应用提供方在开发和部署应用时，可以按照该软件包格式打包应用数据形成软件包，任一对象在获取到该软件包后，都可以根据目录从软件包中读取自身对应的应用数据。如此，可以流程化、规范化、自动化地将各类应用部署在计算平台的不同处理器或域中，可以降低应用开发难度、提高应用部署效率、节省人力成本。
一种可能的设计中，目录包括第一类目录和第二类目录，第一类目录包括指向第一对象的第二类目录的指示信息，第二类目录包括应用数据。
通过该设计方式，第一对象可以根据第一类目录中的指示信息找到第一对象的第二类目录，进而根据第一对象的第二类目录获取到第一对象的应用数据，提高了应用数据的获 取效率，进而提高了应用的部署效率。
一种可能的设计中，在第一对象根据目录从软件包中读取第一对象的应用数据之前，第一对象还根据第一对象的配置将指示信息写入第一类目录中。
通过该设计方式，软件包中不需针对每个对象单独设置一个第一类目录，而是每个对象在拿到软件包后根据自身的配置填充第一类目录，可以有效降低软件包中的数据冗余。并且，对于应用提供方或应用，无需感知应用需要安装在哪些或哪个对象上，可以降低应用的开发难度。
一种可能的设计中，第二类目录还包括至少一个对象中每个对象的第三类目录的指示信息，每个对象的第三类目录指向每个对象的软件数据。
通过该设计方式，第一对象可以根据第二类目录中的指示信息找到第一对象的第三类目录，进而根据第一对象的第三目录获取到第一对象的软件数据，提高了软件数据的获取效率，进而提高了应用的部署效率。
一种可能的设计中，至少一个对象的数量为多个，多个对象中至少两个对象的第三类目录相同。或者说，第二类目录中的至少两个对象的第三类目录的指示信息相同。
通过该设计方式，在软件包中放置的软件数据，可以被多个对象使用，可以有效降低针对不同对象分发不同软件包带来的数据冗余。
一种可能的设计中，指示信息为链接或指针。
当然，此处仅为举例而非限定，实际应用中指示信息还可以是其它形式。
一种可能的设计中，至少一个对象包括多个域，多个域中不同域对应不同的安全级别。
通过该设计方式，软件包可以针对不同安全级别的域分别设计不同的目录，能够同时满足多种功能安全的应用的开发需求。
一种可能的设计中，软件包包括APP分区和签名区，目录位于APP分区中，签名区用于存储签名。相应的，第一对象还可以读取签名区中的签名，根据签名验证软件包的完整性和安全性。
通过该设计方式，第一对象可以在确认软件包完整和安全的情况下再安装应用，可以提高应用部署的可靠性。
一种可能的设计中，签名包括平台签名、应用提供方签名、用户签名中的一项或多项；签名区还包括用于指示签名区中的签名的类型和/或大小的信息。
通过该设计方式，可以提高第一对象解析软件包的效率和准确性。
一种可能的设计中，对象包括车载计算平台中的处理器或处理器中的域。
换而言之，本申请实施例技术方案可以应用于车载计算平台上的应用的开发和部署场景，通过该设计方式，车载计算平台可以流程化、规范化、自动化地将各类应用部署在车载计算平台的不同的处理器或不同的域中，可以降低车载计算平台应用开发难度、提高应用部署效率、节省人力成本。
第二方面，提供一种软件包解析装置，该装置包括用于执行如第一方面或第一方面任一种可能的设计中所述方法的模块或单元或技术手段。
示例性的，该装置可以包括：
获取模块，用于获取软件包，其中，软件包包括目录和至少一个对象的应用数据，目录指示至少一个对象中每个对象的应用数据在软件包中的位置，应用数据包括至少一个对象对应的应用集合、应用集合相关的配置信息，以及应用集合中每个应用对应的软件数据， 对象包括处理器或域；
处理模块，用于：解析软件包，得到目录；以及，根据目录从软件包中读取第一对象的应用数据，第一对象为至少一个对象中的任意一个。
一种可能的设计中，目录包括第一类目录和第二类目录，第一类目录包括指向第一对象的第二类目录的指示信息，第二类目录包括应用数据。
一种可能的设计中，处理模块还用于：在根据目录从软件包中读取第一对象的应用数据之前，根据第一对象的配置将指示信息写入第一类目录中。
一种可能的设计中，第二类目录还包括至少一个对象中每个对象的第三类目录的指示信息，每个对象的第三类目录指向每个对象的软件数据。
一种可能的设计中，至少一个对象的数量为多个，多个对象中至少两个对象的第三类目录相同。
一种可能的设计中，至少一个对象包括多个域，多个域中不同域对应不同的安全级别。
一种可能的设计中，软件包包括APP分区和签名区，目录位于APP分区中，签名区用于存储签名；处理模块还用于：读取签名区中的签名，根据签名验证软件包的完整性和安全性。
一种可能的设计中，签名包括平台签名、应用提供方签名、用户签名中的一项或多项；签名区还包括用于指示签名区中的签名的类型和/或大小的信息。
一种可能的设计中，对象包括车载计算平台中的处理器或处理器中的域。
第三方面，提供一种处理装置，包括：至少一个处理器和接口电路；
所述接口电路用于接收来自所述装置之外的其它装置的信号并传输至所述处理器或将来自所述处理器的信号发送给所述装置之外的其它装置，所述处理器通过逻辑电路或执行代码指令用于实现如第一方面或第一方面任一种可能的设计中所述方法。
第四方面，提供一种终端设备，包括如第二方面或第二方面任一种可能的设计中所述的装置。
可选的，该终端设备为车载终端，通用计算机或服务器。
第五方面，提供一种车辆，包括如第二方面或第二方面任一种可能的设计中所述的装置。
第六方面，提供一种计算机可读存储介质，所述可读存储介质用于存储指令，当所述指令被执行时，使如第一方面或第一方面任一种可能的设计中所述方法被实现。
第七方面，提供一种计算机程序产品，所述计算机程序产品中存储有指令，当其在计算机上运行时，使得计算机执行如第一方面或第一方面任一种可能的设计中所述方法。
上述第二方面至第七方面的有益效果可以参考第一方面对应设计的有益效果，不再赘述。
附图说明
图1为本申请实施例提供的一种应用场景示意图；
图2为车辆100的示意图；
图3为本申请实施例提供的一种软件包解析方法的流程图；
图4为不同对象从软件包中读取应用数据的示意图；
图5为本申请实施例提供的一种软件包解析装置500的示意图；
图6为本申请实施例提供的另一种软件包解析装置600的示意图。
具体实施方式
本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。在本申请的文字描述中，字符“/”，一般表示前后关联对象是一种“或”的关系；在本申请的公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“包括A，B和C中的至少一个”可以表示：包括A；包括B；包括C；包括A和B；包括A和C；包括B和C；包括A、B和C。
本申请实施例提供的技术方案可以应用于任何集中式电子架构的应用开发和/或部署场景。
示例性的，参见图1，为本申请实施例提供一种应用场景示意图，该场景包括至少一个开发者(或称为应用提供方)的设备200和车辆100，车辆100上搭载有车载计算平台110，任意一个开发者的设备200可以在车载计算平台110上部署应用。应用部署过程例如：开发者的设备200向车载计算平台110发送软件包，车载计算平台110可以解析软件包进而获取到开发者的设备200提供的应用数据，并基于应用数据安装应用。车载计算平台110运行应用可以对车辆的各个元件进行访问和控制。
作为一种示例，参见图2，为车辆100的示意图，包括：车载计算平台110、传感器系统120、控制系统130、外围设备140、电源150、用户接口160等。需要说明的是，在其它示例中，车辆100可以包括更多、更少或不同的系统，并且每个系统可以包括更多、更少或不同的组件。此外，示出的系统和组件可以按任意种的方式进行组合或划分，本申请对此不做具体限定。
传感器系统120可以包括用于感测关于车辆100所位于的环境的信息的若干个传感器。如图2所示，传感器系统120的传感器包括全球定位系统(global positioning system，GPS)126、惯性测量单元(inertial measurement unit，IMU)125、激光雷达122、相机传感器123、毫米波雷达124以及用于修改传感器的位置和/或朝向的制动器121。毫米波雷达124可利用无线电信号来感测车辆100的周边环境内的目标。在一些实施例中，除了感测目标以外，毫米波雷达124还可用于感测目标的速度和/或前进方向。激光雷达122可利用激光来感测车辆100所位于的环境中的目标。在一些实施例中，激光雷达122可包括一个或多个激光源、激光扫描器以及一个或多个检测器，以及其他系统组件。相机传感器123可用于捕捉车辆100的周边环境的多个图像。相机传感器123可以是静态相机或视频相机。
控制系统130用于控制车辆100及其组件的操作。控制系统130可包括各种元件，其中包括转向单元136、油门135、制动单元134、传感器融合单元133、计算机视觉系统132、路线控制系统131以及障碍规避系统137。转向单元136可操作来调整车辆100的前进方向。例如在一个实施例中可以为方向盘系统。油门135用于控制引擎114的操作速度并进而控制车辆100的速度。控制系统130可以额外地或可替换地包括除了图2所示出的组件以外的其他组件。本申请对此不做具体限定。
外围设备140可以被配置为用于车辆100与外部传感器、其它车辆和/或用户交互。为此，外围设备140可以包括例如无线通信系统144、触摸屏143、麦克风142和/或扬声器 141。外围设备140可以额外地或可替换地包括除了图2所示出的组件以外的其他组件。本申请对此不做具体限定。
电源150可以被配置为向车辆100的一些或全部组件提供电力。
车载计算平台110具体实现可以是具有处理能力的计算机系统，例如车载计算平台110可以包括移动数据中心(mobile data center，MDC)。
车载计算平台110可以被配置为从传感器系统120、控制系统130和外围设备140等接收数据并对它们进行控制。车载计算平台110还可以被配置为显示在用户接口160上生成图像的显示，或从用户接口160接收输入。
车辆100的部分或所有功能受车载计算平台110控制。车载计算平台110可包括至少一个处理器161，处理器161执行存储在例如存储器163这样的非暂态计算机可读介质中的指令1631。车载计算平台110还可以是采用分布式方式控制车辆100的个体组件或子系统的多个计算设备。
可选的，车载计算平台110还可以包括收发器162，用于实现车载计算平台110与车辆100中的其它部件和/或用于实现车载计算平台110与车辆100之外的其它设备通信。
处理器161可以是任何处理器，诸如片上系统(System-on-Chip，SoC)、中央处理器(central processing unit，CPU)、专用集成电路(application-specific integrated circuit,ASIC)或其它基于硬件的专用处理设备等。尽管图2功能性地图示了处理器、存储器、和其它元件，但是本领域的普通技术人员应该理解，该处理器、存储器实际上可以包括存储在相同的物理外壳内的多个处理器、存储器，或者，该处理器、存储器实际上可以包括不存储在相同的物理外壳内的多个处理器、存储器。例如，存储器可以是硬盘驱动器或位于不同于车载计算平台110的外壳内的其它存储介质。因此，对处理器或计算机的引用将被理解为包括对可以或者可以不并行操作的处理器或存储器的集合的引用。不同于使用单一的处理器来执行此处所描述的步骤，诸如转向组件和减速组件的一些组件每个都可以具有其自己的处理器，所述处理器只执行与特定组件的功能相关的计算。
处理器161可以具有一个或多个域。当处理器161中包含多个域时，不同域之间的运行环境和数据相互隔离，域具体例如为操作系统，如处理器161上可以同时运行多个不同的操作系统。
车载计算平台110可从各种子系统(例如，传感器系统120和控制系统130)以及从用户接口160接收的输入来控制车辆100的功能。
进一步的，车载计算平台110控制车辆100的功能，可以通过运行应用实现。每个处理器161或每个域中的应用均可以通过车载计算平台110对各个元件进行访问和控制，以实现应用对应的功能，其中功能例如包括但不限于智能驾驶、倒车影像、通话、音响等。
实际应用中，不同应用有着不同的功能安全需求；而车载计算平台作为基础能力的提供者，需要对不同应用提供定制化的能力，例如，将不同功能安全需求的应用分别部署在不同安全级别的运行环境，以适配不同应用的功能安全需求。如果单纯依靠人力对应用一一进行适配并部署，则存在应用开发难度高、应用部署效率低、人力成本高等问题。
鉴于以上因素，提供本申请实施例技术方案，该方案中设计了一种与车载计算平台应用解耦的软件包格式，使得车载计算平台可以流程化、规范化、自动化地将各类应用部署在不同的处理器或不同的域中，可以降低应用开发难度、提高应用部署效率、节省人力成本。
需要说明的是，图1、图2仅为一种示例，本申请实施例提供的技术方案还可以应用于其它集中式电子架构的设备。为了便于描述，本文主要以图1、图2所示的场景为例对本申请实施例进行详细描述。
参见图3，为本申请实施例提供的一种软件包解析方法的流程图，方法包括步骤S301-S303。
S301、第一对象获取软件包。
本申请实施例中，对象包括处理器或域或者其它能够解析软件包的主体，本申请不做限制。第一对象为一个载体中的至少一个对象中的任意一个，例如，第一对象是一个处理器，或者是一个处理器上的一个域。该载体可以是任何需要安装软件的装置或平台。
可以理解，当第一对象为一个处理器上的一个域时，第一对象可以通过处理器标识和域标识共同标识，也可以单独由域标识进行标识，本申请不做限制。例如，不同处理器具有不同的处理器标识，但是不同处理器上的域可以复用相同的域标识，则需要通过处理器标识+域标识来区分不同处理器上的域；例如，不同处理器上的域不能复用相同的域标识，则单独通过域标识即可区分不同处理器上的域和区分同一处理器上的不同域。
一种可能设计中，对象包括车载计算平台中的处理器或处理器中的域。例如，第一对象为车载计算平台上的一个SoC，或者第一对象为车载计算平台上的一个SoC的一个操作系统。
进一步的，第一对象获取软件包，具体可以是车载计算平台通过通信接口(如车载盒子(T-Box))接收来自应用提供方的服务器的软件包，或者车载计算平台从用户接口接收用户输入的软件包，等等，本申请不做限制。
通常情况下，车载计算平台提供商可以在车载计算平台出厂时将平台基础软件及用户软件包统一安装到固定分区内，在车辆空中下载(over-the-air，OTA)过程中可以更新车载计算平台上的软件包。本申请实施例中的软件包，可以是车载计算平台出厂时安装的软件包，也可以是车辆在OTA过程中升级的软件包，本申请不做限制。
一种可能的设计中，至少一个对象包括多个域，多个域中不同域对应不同的安全级别。
其中，域的安全级别可以表征域能够提供的功能安全能力，例如域的安全级别越高，域的功能安全能力越高，适合部署高功能安全需求的应用。
功能安全，可以理解为：不存在由于电子/电气系统的功能异常表现引起的危险而导致的不合理风险(absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems)。
域提供的功能安全能力越高，表示应用在该域运行时，电子/电气系统的功能异常表现引起危险的风险越低，或者电子/电气系统的功能异常表现引起的危险的危险程度越低。
一个具体的示例中，安全级别可以是国际标准化组织(international organization for standardization，ISO)26262定义的安全完整性等级(automotive safety integrity level，ASIL)，包括四个等级：ASIL-A,ASIL-B,ASIL-C和ASIL D。其中ASIL-A为最低的安全完整性等级，能够最低程度地降低汽车电子/电气系统的功能异常表现引起的危害导致的不合理风险(可以代表最低的功能安全能力)；ASIL-D为最高的安全完整性等级，能够最高程度地降低汽车电子/电气系统的功能异常表现引起的危害导致的不合理风险(可以代表最高的功能安全能力)。
应用的功能安全需求(或者称为功能安全要求)，可以理解为：应用在部署时，对自 身的运行环境的功能安全能力的要求。
一般来说，应用的功能安全需求越高，应用希望电子/电气系统的功能异常表现引起的危险而导致的不合理风险越低，应用对域的功能安全能力要求越高，应用需要部署在安全级别较高的运行环境中。
例如，域为车载计算平台的上操作系统，可以按照各操作系统对应的安全级别，将操作系统分为不同的域，例如安全执行域(secure executable environment，SEA)和通用执行域(general executable environment，GEA)两种域。其中，SEA用于提供高功能安全能力的运行环境，如ASIL-B级的运行环境，主要用于部署对算力要求高且有高安全功能需求的应用。GEA用于提供低功能安全能力的运行环境，如ASIL-A级的运行环境，主要用于部署对算力要求低且有低安全功能需求较低的应用。
SEA域与GEA域的划分，可以方便应用提供方根据应用的功能安全要求部署应用，可以提高用户体验与整车性能。
应理解，这里SEA域与GEA域的划分仅为一种示例而非限定，实际应用中还可以有其它更多类型的域的划分，本申请不做限制。
上述软件包包括至少一个对象的应用数据。
其中，应用数据包括但不限于以下三种：
(1)至少一个对象对应的应用集合；
应用集合用于指示软件包中有哪些应用的安装数据。例如，应用集合中包含至少一个应用的标识，该标识例如为应用的名称(如test_app、demo_app等)，或者应用的编号等。其中，应用可以包括通过执行管理器(Execution Management，EM)自动拉起的应用，通过EM手动拉起(pull)的应用，或者通过其它方式拉起的应用，等等，本申请不做限制。
在一些可能的实施方式中，应用也可以称为进程。上述应用集合可以是应用列表、包括应用信息的文件或其他格式的数据。
(2)应用对应的软件数据；
应用对应的软件数据为应用的安装数据中的一种，主要是指应用对应的可执行文件(bin)和公共库(lib)等。其中，可执行文件包括但不限于应用启动时或使用时或手动调测时使用的可执行文件。
(3)应用集合相关的配置信息；
应用集合相关的配置信息可以包括应用集合中每个应用对应的配置信息。每个应用对应的配置信息为应用的安装数据中的一种。
例如，每个应用对应的配置信息包括但不限于以下一种或多种：应用的配置文件(conf)、应用的启动脚本(script)、应用的其它文件(etc)，等等。
可以理解的，在一些实现方式中，同一个配置信息可能对应多个不同的应用。
上述软件包还包括目录。目录指示至少一个对象中每个对象的应用数据在软件包中的位置。
其中，每个对象的应用数据在软件包中的位置，例如包括软件数据的存放路径和配置信息的存放路径。
一种可能的设计中，目录包括第一类目录和第二类目录，第一类目录包括指向第一对象的第二类目录的指示信息。第二类目录中包括应用数据，可以理解，这里的应用数据可以是部分应用数据也可以是全部应用数据，不做限制，例如第二类目录中至少包括应用集 合和应用集合相关的配置信息。通过该设计，可以提高对象查找应用数据的效率。
可选的，指示信息为链接、指针或者其它类型的指示信息。
可选的，第一类目录的初始值为空或者0，在第一对象根据目录从软件包中读取第一对象的应用数据之前，第一对象先根据第一对象的配置将指示信息写入第一类目录中，进而后续在从软件包中读取第一对象的应用数据的过程中，可以根据第一类目录中的指示信息找到第一对象对应的第二类目录。
其中，第一对象的配置具体可以是第一对象的标识，例如处理器标识、或者域标识、或者处理器标识+域标识等。
一种可能的设计中，一个车载计算平台中有多片SoC、一个微控制单元(microcontroller unit，MCU)，每个SoC都与该MCU通信连接，MCU可以向每一个SoC传递一个唯一的标识符号作为该SoC的处理器标识，每个SoC可以根据接收到的标识符号对软件包进行识别，从软件包中确定出自身对应的应用数据。进一步的，SoC中存在多个域时，每个域还可以根据自身的域标识从软件包中确定自身对应的应用数据。
为了便于理解，这里以至少一个对象为四个对象为例，该四个对象分别为：SoC 0中的GEA域、SoC 0中的SEA域、SoC 1中的GEA域、SoC 1中的SEA域。软件包中的第一类目录有两个，分别为gea和sea；第二类目录有四个，分别为：gea_a、gea_b、sea_a、sea_b。参见表1，为一种可能的目录格式的示例。
表1
Figure PCTCN2022140103-appb-000001
一种可能的设计中，第二类目录还包括至少一个对象中每个对象的软件数据。仍以上述四个对象为例，表2为另一种可能的目录格式的示例。
表2
Figure PCTCN2022140103-appb-000002
一种可替换的设计中，第二类目录还包括至少一个对象中每个对象的第三类目录的指示信息，每个对象的第三类目录指向每个对象的软件数据。
可选的，该指示信息可以为链接、指针。当然，此处仅为举例而非限定，实际应用中指示信息还可以是其它形式。
仍以上述四个对象为例，表3为另一种可能的目录格式的示例。
表3
Figure PCTCN2022140103-appb-000003
一种可能的示例中，至少一个对象的数量为多个。多个对象中至少两个对象的第三类目录相同，或者说，第二类目录中的至少两个对象的第三类目录的指示信息相同。如此，在软件包中放置的软件数据可以被多个对象使用，可以有效降低针对不同对象分发不同软件包带来的数据冗余。
需要说明的是，上文表1、表2、表3所例举的目录格式仅为示例而非限定，实际应用中，可以根据车载计算平台上的对象的具体情况对目录进行灵活地拓展。例如，当有车载计算平台上有三片SoC时，则第二类目录还可拓展多一个gea_c目录和一个sea_c目录，以此类推。
一种可能的设计中，第三类目录中还可以存在至少部分子目录和第二目录中的至少部分子目录相同。但是同一个数据，仅在第三类目录或第二类目录中保存。
例如，在第三类目录和第二类目录均存在子目录A，但第二类目录中的子目录A下存放的是跳转至第三类目录中的子目录A的链接，第三类目录中的子目录A指向软件数据。
例如，在第三类目录和第二类目录均存在子目录B，但第二类目录中的子目录B下存放的是配置信息，而第三类目录中的子目录B为空。
为了便于理解，这里例举一个详细示例，如表4所示。
表4
Figure PCTCN2022140103-appb-000004
Figure PCTCN2022140103-appb-000005
Figure PCTCN2022140103-appb-000006
表5为表4中各个子目录的解释说明：
表5
Figure PCTCN2022140103-appb-000007
Figure PCTCN2022140103-appb-000008
从表4可以看出，第三类目录(如entity_gea)与第二类目录(如gea_a或gea_b)的目录结构相同，但是entity_gea和gea_a或gea_b有区别：gea_a或gea_b中的bin目录下是跳转到entity_gea下的bin目录的链接(并未直接指向可执行文件)，如“../../../entity_gea/runtime_service/demo_app_1/bin；gea_a或gea_b中的lib目录下存放的是跳转到entity_gea下的lib目录的链接(并未直接指向公共库)，如“../../entity_gea/bin”。entity_gea中的bin目录和lib目录下才是真正分别指向可执行文件和公共库。entity_gea中的bin目录指向的可执行文件是gea_a对应的可执行文件、gea_b对应的可执行文件的合集，entity_gea中的lib目录指向的可执行文件是gea_a对应的公共库、gea_b对应的公共库的合集，例如gea_a和gea_b都有demo_app_1，entity_gea中针对demo_app_1下只存了一份数据，gea_a中demo_app_1的bin和gea_b中demo_app_1的bin指向entity_gea中的同一个位置，即“entity_gea/runtime_service/demo_app_1/bin”。
需要说明的是，gea_a或gea_b中任意bin下的链接，可以指向entity_gea中相对位置相同的bin(如gea_a中manual_service下test_app下的bin指向entity_gea中manual_service下test_app下的bin)，也可以指向其它位置的bin(如gea_a中manual_service下test_app下的bin也可以指向entity_gea下的bin)，本申请不做限制。
表4所给的目录结构仅为示例，而非限定。
通过该设计方式，可以使得软件包的目录结构更加工整和简单，且可以减少冗余数据。
可以理解，上文所列举的目录结构均是以至少一个对象为多个对象为例，在实际应用中，当车载计算平台为单处理器单域的情况时，目录结构还可以进一步简化。
例如，参见表6，为单域目录结构的示意图。单域目录内所有的原始文件都放置在entity_gea下，gea_a和gea_b只有指向entity_gea目录下对应文件的链接。
表6
Figure PCTCN2022140103-appb-000009
S302、第一对象解析软件包，得到目录。
示例性的，车载计算平台在启动时(包括冷启动和热启动)，车载计算平台上的SoC(具体可以是SoC中的一个域，该域可以是车载计算平台上最先启动的域)对软件包执行 挂载动作，然后通过文件系统驱动(如ext2驱动、ext3驱动、ext4驱动等)识别软件包，进而读取到软件包的目录。SoC上的各个域的启动时，分别对软件包执行填充第一类目录动作。
可以理解的，在常见操作系统(如linux系统)中，所有文件都放置在以根目录为树根的树形目录结构中。第一对象获取到软件包后，软件包在初始状态下并不在这个树形目录结构中，第一对象执行挂载动作就是在树形目录中找到一个位置建立挂载点，将软件包挂载到这个位置，从而后续SoC中的域可以从该挂载点进入软件包，读取软件包的目录。
S303、第一对象根据目录从软件包中读取第一对象的应用数据。
仍以上文所举四个对象为例(即SoC 0中的GEA域、SoC 0中的SEA域、SoC 1中的GEA域、SoC 1中的SEA域，第一对象可以是其中任意一个)，参见图4，为各个对象从软件包中读取应用数据的示意图。可以理解，SoC 0中的GEA域、SoC 0中的SEA域、SoC1中的GEA域、SoC 1中的SEA域分别对应不同的第二类目录(即gea_a、sea_a、gea_b、sea_b)。在图4中，为了清楚示出gea_a、sea_a、gea_b、sea_b区别，将gea_a、sea_a、gea_b、sea_b中不同的配置信息用“差异配置”表示，如conf、machine等。此外，在图4中，第二类目录中指向第三类目录的指示信息均以链接为例，即“相对路径符号链接”，实际不限于此。
SoC 0中的GEA域获取到该软件包后，可以根据自身的配置在gea目录中写入gea_a的指示信息。SoC 0中的GEA域在启动软件包安装后，根据gea目录中的gea_a的指示信息找到gea_a目录，从gea_a目录中读取配置信息(如conf、test_app等)，以及根据gea_a目录中的链接找到entity_gea目录下的软件数据(如bin文件和lib文件)，最后基于获取到的所有数据完成应用的安装。
SoC 0中的SEA域获取到该软件包后，可以根据自身的配置在sea目录中写入sea_a的指示信息。SoC 0中的SEA域在启动软件包安装后，根据sea目录中的sea_a的指示信息找到sea_a目录，从sea_a目录中读取配置信息(如conf、test_app等)，以及根据sea_a目录中的链接找到entity_sea目录下的软件数据(如bin文件和lib文件)，最后基于获取到的所有数据完成应用的安装。
SoC 1中的GEA域获取到该软件包后，可以根据自身的配置在gea目录中写入gea_b的指示信息。SoC 1中的GEA域在启动软件包安装后，根据gea目录中的gea_b的指示信息找到gea_b目录，从gea_b目录中读取配置信息(如conf、test_app等)，以及根据gea_b目录中的链接找到entity_gea目录下的软件数据(如bin文件和lib文件)，最后基于获取到的所有数据完成应用的安装。
SoC 1中的SEA域获取到该软件包后，可以根据自身的配置在sea目录中写入sea_b的指示信息。SoC 1中的GEA域在启动软件包安装后，根据sea目录中的sea_b的指示信息找到sea_b目录，从sea_b目录中读取配置信息(如conf、test_app等)，以及根据sea_b目录中的链接找到entity_sea目录下的软件数据(如bin文件和lib文件)，最后基于获取到的所有数据完成应用的安装。
在上述方案中，软件包格式包括目录和至少一个对象的应用数据。应用提供方在开发和部署应用时，可以按照该软件包格式打包应用数据形成软件包，任一对象在获取到该软件包后，都可以根据目录从软件包中读取自身对应的应用数据。如此，车载计算平台可以流程化、规范化、自动化地将各类应用部署在不同处理器或域中，可以降低应用开发难度、 提高应用部署效率、节省人力成本。并且，后续在对车载计算平台进行应用升级时，也可以采用该方案单独对车载计算平台上的部分应用升级，而不影响其它应用。此外，当软件包中单个应用的应用数据出现异常崩溃时，不会影响其他应用的应用数据，也不会影响车载计算平台的正常工作。
一种可能的设计中，软件包包括APP分区和签名区，上述目录和应用数据位于APP分区中，签名区用于存储签名。相应的，第一对象在获取到软件包之后，还可以读取签名区中的签名，根据签名验证软件包的完整性和安全性。在确认软件包的完整和安全后，再安装应用。比如，车载计算平台在启动时(包括冷启动和热启动)，处理器先对软件包执行签名验证，在签名验证通过后，再挂载软件包、读取软件包的目录等。
一个具体的示例中，签名可以包括平台签名、应用提供方签名、用户签名等中的一项或多项，本申请不做限制。以车载场景为例，平台签名可以是车载计算平台的签名，应用提供方签名可以是需要在车载计算平台上提供应用服务的商家的签名，用户签名可以是车主的签名。
以用户签名为例，用户对用户APP分区中的内容进行哈希计算得到第一哈希摘要，并对第一哈希摘要进行签名，签名后的结果置于数字签名附加字段中用户签名头位置。当车载计算平台加载用户软件包时，将再次对用户APP分区中的内容进行计算，得到第二哈希摘要，并使用工作证书获取签名的第一哈希摘要，将第一哈希摘要和第二哈希摘要进行比较，若相同可以确保用户软件包的完整性和安全性。
如此，可以提高应用部署的可靠性。
一种可能的设计中，签名区还可以包括用于指示签名区中的签名的类型和/或大小的信息。例如，在签名区的开头设置二级头，用于指示签名区中的签名的类型和/或大小。
如此，可以提高第一对象解析软件包的效率和准确性。
以上结合附图介绍了本申请实施例提供的方法，以下结合附图介绍本申请实施例提供的装置。
基于相同的技术构思，本申请实施例提供一种软件包解析装置500，该软件包解析装置500包括用于执行上述方法实施例中第一对象所执行的方法的模块/单元/手段。该模块/单元/手段可以通过软件实现，或者通过硬件实现，也可以通过硬件执行相应的软件实现。
示例性的，参见图5，软件包解析装置500可以包括：
获取模块501，用于获取软件包，其中，软件包包括目录和至少一个对象的应用数据，目录指示至少一个对象中每个对象的应用数据在软件包中的位置，应用数据包括至少一个对象对应的应用集合、应用集合相关的配置信息，以及应用集合中每个应用对应的软件数据，对象包括处理器或域；
处理模块502，用于：解析软件包，得到目录；以及，根据目录从软件包中读取第一对象的应用数据，第一对象为至少一个对象中的任意一个。
应理解，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
基于相同的技术构思，参见图6，本申请实施例还提供一种软件包解析装置600，该装置600包括至少一个处理器601和接口电路602；接口电路602用于接收来自该装置600之外的其它装置的信号并传输至处理器601或将来自处理器601的信号发送给该装置之外的其它装置，处理器601通过逻辑电路或执行代码指令用于实现上述方法实施例中第一对 象所执行的方法。
应理解，本申请实施例中提及的处理器可以通过硬件实现也可以通过软件实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等。当通过软件实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现。
示例性的，处理器可以是中央处理单元(central processing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
基于相同技术构思，本申请实施例还提供一种计算机可读存储介质，包括程序或指令，当所述程序或指令在计算机上运行时，使得如上述方法实施例中第一对象所执行的方法被执行。
基于相同技术构思，本申请实施例还提供一种包含指令的计算机程序产品，该计算机程序产品中存储有指令，当其在计算机上运行时，使得如上述方法实施例中第一对象所执行的方法被执行。
基于相同技术构思，本申请实施例还提供一种终端设备，包括上述软件包解析装置。终端设备可以是车辆、无人机、直升机、飞机、轮船、智能运输设备、或智能家居设备等。本申请实施例对终端设备的具体形态不做限定。
应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。
需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。
应注意，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
以上所述，仅为本申请的部分实施例，显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的保护范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (22)

  1. 一种软件包解析方法，其特征在于，包括：
    第一对象获取软件包，其中，所述软件包包括目录和至少一个对象的应用数据，所述目录指示所述至少一个对象中每个对象的应用数据在所述软件包中的位置，所述应用数据包括所述至少一个对象对应的应用集合、所述应用集合相关的配置信息，以及所述应用集合中每个应用对应的软件数据，所述对象包括处理器或域；
    所述第一对象解析所述软件包，得到所述目录；
    所述第一对象根据所述目录从所述软件包中读取所述第一对象的应用数据，所述第一对象为所述至少一个对象中的任意一个。
  2. 如权利要求1所述的方法，其特征在于，所述目录包括第一类目录和第二类目录，所述第一类目录包括指向所述第一对象的第二类目录的指示信息，所述第二类目录包括所述应用数据。
  3. 如权利要求2所述的方法，其特征在于，在所述第一对象根据所述目录从所述软件包中读取所述第一对象的应用数据之前，所述方法还包括：
    所述第一对象根据所述第一对象的配置将所述指示信息写入所述第一类目录中。
  4. 如权利要求2或3所述的方法，其特征在于，所述第二类目录还包括所述至少一个对象中每个对象的第三类目录的指示信息，所述每个对象的第三类目录指向所述每个对象的软件数据。
  5. 如权利要求4所述的方法，其特征在于，所述至少一个对象的数量为多个，所述多个对象中至少两个对象的第三类目录相同。
  6. 如权利要求1-5任一项所述的方法，其特征在于，所述至少一个对象包括多个域，所述多个域中不同域对应不同的安全级别。
  7. 如权利要求1-6任一项所述的方法，其特征在于，所述软件包包括应用程序APP分区和签名区，所述目录位于所述APP分区中，所述签名区用于存储签名；
    所述方法还包括：
    所述第一对象读取所述签名区中的签名，根据所述签名验证所述软件包的完整性和安全性。
  8. 如权利要求7所述的方法，其特征在于，所述签名包括平台签名、应用提供方签名、用户签名中的一项或多项；
    所述签名区还包括用于指示所述签名区中的签名的类型和/或大小的信息。
  9. 如权利要求1-8任一项所述的方法，其特征在于，所述对象包括车载计算平台中的处理器或处理器中的域。
  10. 一种软件包解析装置，其特征在于，包括：
    获取模块，用于获取软件包，其中，所述软件包包括目录和至少一个对象的应用数据，所述目录指示所述至少一个对象中每个对象的应用数据在所述软件包中的位置，所述应用数据包括所述至少一个对象对应的应用集合、所述应用集合相关的配置信息，以及所述应用集合中每个应用对应的软件数据，所述对象包括处理器或域；
    处理模块，用于：
    解析所述软件包，得到所述目录；以及
    根据所述目录从所述软件包中读取所述第一对象的应用数据，所述第一对象为所述至少一个对象中的任意一个。
  11. 如权利要求10所述的装置，其特征在于，所述目录包括第一类目录和第二类目录，所述第一类目录包括指向所述第一对象的第二类目录的指示信息，所述第二类目录包括所述应用数据。
  12. 如权利要求11所述的装置，其特征在于，所述处理模块还用于：
    在根据所述目录从所述软件包中读取所述第一对象的应用数据之前，根据所述第一对象的配置将所述指示信息写入所述第一类目录中。
  13. 如权利要求11或12所述的装置，其特征在于，所述第二类目录还包括所述至少一个对象中每个对象的第三类目录的指示信息，所述每个对象的第三类目录指向所述每个对象的软件数据。
  14. 如权利要求13所述的装置，其特征在于，所述至少一个对象的数量为多个，所述多个对象中至少两个对象的第三类目录相同。
  15. 如权利要求10-14任一项所述的装置，其特征在于，所述至少一个对象包括多个域，所述多个域中不同域对应不同的安全级别。
  16. 如权利要求10-15任一项所述的装置，其特征在于，所述软件包包括应用程序APP分区和签名区，所述目录位于所述APP分区中，所述签名区用于存储签名；
    所述处理模块还用于：
    读取所述签名区中的签名，根据所述签名验证所述软件包的完整性和安全性。
  17. 如权利要求16所述的装置，其特征在于，所述签名包括平台签名、应用提供方签名、用户签名中的一项或多项；
    所述签名区还包括用于指示所述签名区中的签名的类型和/或大小的信息。
  18. 如权利要求10-17任一项所述的装置，其特征在于，所述对象包括车载计算平台中的处理器或处理器中的域。
  19. 一种处理装置，其特征在于，包括：至少一个处理器和接口电路；
    所述接口电路用于接收来自所述装置之外的其它装置的信号并传输至所述处理器或将来自所述处理器的信号发送给所述装置之外的其它装置，所述处理器通过逻辑电路或执行代码指令用于实现如权利要求1-9中任一项所述的方法。
  20. 一种终端设备，其特征在于，包括如权利要求10-18中任一项所述的装置。
  21. 一种车辆，其特征在于，包括如权利要求20所述的终端设备。
  22. 一种计算机可读存储介质，其特征在于，所述可读存储介质用于存储指令，当所述指令被执行时，使如权利要求1-9中任一项所述的方法被实现。
PCT/CN2022/140103 2022-12-19 2022-12-19 一种软件包解析方法、装置和车辆 WO2024130501A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/140103 WO2024130501A1 (zh) 2022-12-19 2022-12-19 一种软件包解析方法、装置和车辆

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/140103 WO2024130501A1 (zh) 2022-12-19 2022-12-19 一种软件包解析方法、装置和车辆

Publications (1)

Publication Number Publication Date
WO2024130501A1 true WO2024130501A1 (zh) 2024-06-27

Family

ID=91587328

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/140103 WO2024130501A1 (zh) 2022-12-19 2022-12-19 一种软件包解析方法、装置和车辆

Country Status (1)

Country Link
WO (1) WO2024130501A1 (zh)

Similar Documents

Publication Publication Date Title
US20230012366A1 (en) Error-resilient over-the-air software updates for vehicles
US20220113958A1 (en) Function extension system and electronic control device
WO2019195781A1 (en) Secure compliance protocols
CN113608898A (zh) 指纹访问方法、装置、设备及存储介质
US11836475B2 (en) Electronic control unit, software update method, software update program product and electronic control system
US11935341B2 (en) Data storage device and non-transitory tangible computer readable storage medium
CN113824795A (zh) 车端与云端的通信方法、装置、系统
Aust Paving the way for connected cars with adaptive AUTOSAR and AGL
US20220308857A1 (en) Control device and terminal device
WO2024130501A1 (zh) 一种软件包解析方法、装置和车辆
US20210084464A1 (en) In-vehicle control device, information processing device, vehicle network system, method of providing application program, and recording medium with program recorded thereon
US20210349855A1 (en) Method of data structuring for difference between old and new data and device thereof
US20220171613A1 (en) Electronic control unit, software update method, software update program product and electronic control system
DE102022122162A1 (de) Eingebettete systemzeiterfassung bei automobilen
DE102022120276A1 (de) Austausch von flüchtigen schlüsseln zwischen fahrzeugsoftwareknoten
CN115454403A (zh) 页面搭建方法、装置及存储介质
CN111373384A (zh) 服务器装置、车载设备和数据通信方法
EP3754486B1 (en) Selectively installing applications based on manifest files
US11288665B2 (en) TAAS for delay tolerant blockchain networks
CN117242428A (zh) 软件升级方法和相关产品
JP2003280902A (ja) マイコンロジック開発システム及びそのプログラム
JP7484746B2 (ja) 車両用装置、車両用システム
US20220284743A1 (en) Center device and in-vehicle electronic control device
US11836476B2 (en) Electronic control unit, software update method, software update program product and electronic control system
US20230367623A1 (en) Method and motor vehicle controller for operating a container virtualization with logging function, as well as computer-readable storage medium