System, method, and computer program for vehicle software development

Abstract

Write and test applications directly in the vehicle without the need for dedicated hardware and facilities. The system includes a storage device storing computer-executable instructions and at least one processor communicatively coupled to the storage device, the at least one processor configured to execute instructions to receive an encryption key, authenticate the received encryption key, and, in response to successful authentication of the received encryption key, initiate a development configuration of the vehicle, the development configuration including a primary ECU of the vehicle including multiple partitions and a secondary ECU of the vehicle acting as a RAM disk for the primary ECU, and, in response to detecting erasure of the received encryption key from the vehicle, terminate the development configuration and erase the memory of the secondary ECU.

Description

[Technical Field]

[0001] Systems, methods, and computer programs consistent with embodiments of the present disclosure relate to vehicle software development. [Background technology]

[0002] Modern vehicles are capable of performing a wide range of complex functions, such as generating telemetry data, sending and receiving data over the Internet, etc. To enable the vehicle to perform these functions, the vehicle is essentially connected to an upstream server. This capability allows modern vehicles to create a fun and enriching experience for the driver operating the vehicle through interactive applications.

[0003] Related techniques may require specialized hardware and facilities to develop and test such interactive applications in vehicles.

[0004] However, such approaches to developing and testing applications (vehicle software) in the related art may have at least the following drawbacks: Because specialized hardware and equipment are required, developing and testing applications for vehicles can be custom, difficult, and expensive for developers. To avoid these problems, developers may be forced to rely on existing frameworks such as Android Auto® or Apple CarPlay®. However, such solutions are limited in functionality because they do not provide a means to write and test applications directly in the vehicle.

[0005] Therefore, there is a need for a system that allows applications to be written and tested directly in the vehicle without the need for dedicated hardware and equipment. Summary of the Invention

[0006] Exemplary embodiments of the present disclosure perform vehicle software development and allow applications to be written and tested directly in the vehicle without the need for dedicated hardware and equipment.

[0007] According to an example embodiment, a system is provided that includes a storage device storing computer-executable instructions and at least one processor communicatively coupled to the storage device, the at least one processor configured to execute the instructions to receive an encryption key, authenticate the received encryption key, and in response to successful authentication of the received encryption key, initiate a development configuration of a vehicle, the development configuration including a primary electronic control unit (ECU) of the vehicle including a plurality of partitions and a secondary ECU of the vehicle acting as a RAM disk for the primary ECU, and in response to detecting erasure of the received encryption key from the vehicle, terminate the development configuration and erase the memory of the secondary ECU.

[0008] According to an example embodiment, at least one processor may be configured to execute instructions to initiate a development configuration by selecting a primary ECU and a secondary ECU based on a predetermined configuration file.

[0009] According to an example embodiment, the primary ECU and secondary ECU may be communicatively coupled via a PCI Express interface.

[0010] According to an example embodiment, at least one processor may be configured to execute instructions to initiate a development configuration by unlocking portions of a plurality of partitions of a primary ECU.

[0011] According to an example embodiment, the released portion of the primary ECU's partitions may include at least one of a partition containing virtual machines related to non-safety related functions of the vehicle, a partition containing virtual machines related to a software development framework, and a partition containing user data.

[0012] According to an example embodiment, the at least one processor may be further configured to execute instructions to initiate a development configuration by providing a development environment on the secondary ECU.

[0013] According to an example embodiment, the primary ECU may be associated with multiple vehicle functions, and the multiple functions may be accessible to a user via a development environment and unlocked portions of multiple partitions of the primary ECU.

[0014] According to an example embodiment, at least one processor may be configured to execute instructions to provide the development environment by receiving one or more instructions from a user to save functions of a primary ECU to a development environment, saving the functions to a secondary ECU, and exporting the saved functions to a device.

[0015] According to an example embodiment, at least one processor may be configured to execute instructions to establish a development environment by receiving one or more instructions from a user to access a function of a primary ECU in a development environment, determining whether the function is stored in a secondary ECU, accessing the function stored in the secondary ECU in response to determining that the function is stored in the secondary ECU, and accessing the function stored in the primary ECU in response to determining that the function is not stored in the secondary ECU, and transmitting results of accessing the function to the development environment.

[0016] According to an example embodiment, a method is provided, the method including receiving an encryption key, authenticating the received encryption key, and initiating a development configuration of a vehicle in response to successful authentication of the received encryption key, the development configuration including a primary electronic control unit (ECU) of the vehicle including a plurality of partitions and a secondary ECU acting as a RAM disk for the primary ECU, the method further including terminating the development configuration and erasing the memory of the secondary ECU in response to detecting erasure of the received encryption key from the vehicle.

[0017] According to an example embodiment, initiating a development configuration may include selecting a primary ECU and a secondary ECU based on a predetermined configuration file.

[0018] According to an example embodiment, the primary ECU and secondary ECU may be communicatively coupled via a PCI Express interface.

[0019] According to an example embodiment, initiating a development configuration may include unlocking portions of multiple partitions of a primary ECU.

[0020] According to an example embodiment, the unlocked portions of the primary ECU's partitions may include at least one of a partition containing virtual machines related to non-safety related functions of the vehicle, a partition containing virtual machines related to a software development framework, and a partition containing user data.

[0021] According to an example embodiment, initiating the development configuration may further include providing a development environment on the secondary ECU.

[0022] According to an example embodiment, the primary ECU may be associated with multiple vehicle functions, and the multiple functions may be accessible to a user via a development environment and un-unlocked portions of multiple partitions of the primary ECU.

[0023] According to an example embodiment, providing the development environment may include receiving one or more instructions from a user to save functions of a primary ECU in the development environment, saving the functions to a secondary ECU, and exporting the saved functions to a device.

[0024] According to an example embodiment, providing the development environment may include receiving one or more instructions from a user in the development environment to access a function of the primary ECU; determining whether the function is stored in the secondary ECU; accessing the function stored in the secondary ECU in response to determining that the function is stored in the secondary ECU; and accessing the function stored in the primary ECU in response to determining that the function is not stored in the secondary ECU; and transmitting results of accessing the function to the development environment.

[0025] According to an exemplary embodiment, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium may have instructions executable by at least one processor stored thereon. The instructions cause the at least one processor to perform a method including receiving an encryption key, authenticating the received encryption key, and initiating a development configuration of a vehicle in response to successful authentication of the received encryption key. The development configuration includes a primary electronic control unit (ECU) of the vehicle including multiple partitions and a secondary ECU acting as a RAM disk for the primary ECU. The method further includes terminating the development configuration and erasing the memory of the secondary ECU in response to detecting that the received encryption key has been erased from the vehicle.

[0026] According to an example embodiment, initiating a development configuration may include selecting a primary ECU and a secondary ECU based on a predefined configuration file.

[0027] Additional embodiments are set forth in part in the description that follows, and in part will be obvious from the description, or may be realized by practice of the embodiments described in this disclosure. [Brief explanation of the drawings]

[0028] The features, advantages, and significance of exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings. [Figure 1] FIG. 1 is a block diagram of an example system configuration for vehicle software development according to one or more embodiments. [Figure 2] FIG. 2 is a block diagram of example elements of a primary ECU according to one or more embodiments. [Figure 3] FIG. 3 is a block diagram of example components of a Vehicle Software Development (VSD) system in accordance with one or more embodiments. [Figure 4] FIG. 4 is a flow diagram of an example method for vehicle software development according to one or more embodiments. [Figure 5] FIG. 5 is a flow diagram of an example method for initiating a development configuration of a vehicle according to one or more embodiments. [Figure 6A] FIG. 6A is a flow diagram of an example method for providing a development environment on a secondary ECU according to one or more embodiments. [Figure 6B] FIG. 6B is a flow diagram of an example method for providing a development environment on a secondary ECU according to one or more embodiments. [Figure 7] FIG. 7 is a diagram illustrating example interactions between a primary ECU, a secondary ECU, and user equipment in accordance with one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0029] In the following detailed description of the exemplary embodiments, reference is made to the accompanying drawings, in which the same reference numbers in different drawings may indicate the same or similar elements.

[0030] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations are possible in light of the above disclosure and may result from practice of the implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with other embodiments (or one or more features of other embodiments). Additionally, in the following flowcharts and method descriptions, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be changed.

[0031] It is apparent that the systems and / or methods described in this disclosure may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized hardware or software code used to implement these systems and / or methods does not limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware can be designed to implement the systems and / or methods based on the description in this disclosure.

[0032] Although particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or specifically disclosed in the specification. Although each dependent claim described below depends directly on only a single claim, the disclosure of possible implementations includes the combination of each dependent claim with all other claims in the set.

[0033] No element, act, or instruction in this disclosure should be construed as critical or essential unless expressly stated to that effect. Also, in this disclosure, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar term is used. Also, in this disclosure, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based, at least in part, on," unless expressly stated to the contrary. Furthermore, expressions such as "at least one of [A] and [B]," "[A] and / or [B]," or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0034] The features, advantages and implications of the exemplary embodiments described above are considered to be only part of this disclosure and are not intended to be exhaustive or limit the scope of this disclosure.

[0035] The following provides a detailed description of the features, elements, configuration, operation, and implementation of a vehicle software development system in one or more embodiments. [System architecture example]

[0036] 1 is a block diagram of a system configuration 100 for developing vehicle software, according to one or more embodiments. As shown in FIG. 1, the system configuration 100 may include a user 110 and a vehicle software development (VSD) system 120.

[0037] VSD system 120 may include a device, system, platform, module, etc., and may be configured to perform one or more operations or actions for developing vehicle software. According to an example embodiment, VSD system 120 may include a vehicle. According to an example embodiment, VSD system 120 may be implemented in a vehicle. According to an example embodiment, VSD system 120 may include multiple ECUs (Electronic Control Units) of the vehicle, each of the multiple ECUs configured to control one or more electrical systems of the vehicle. For example, the multiple ECUs may include an In-Vehicle Infotainment (IVI) ECU configured to control electrical systems related to infotainment in the vehicle.

[0038] According to an exemplary embodiment, the VSD system may be configured with the development and production configurations of the vehicle.

[0039] A development configuration of a vehicle may refer to a configuration of the vehicle in which only some of the vehicle's subsystems are unlocked for access by a user 110 (software developer) to perform software development for the vehicle. In particular, the development configuration may identify one ECU from multiple ECUs in the vehicle as a primary ECU and another ECU from multiple ECUs in the vehicle as a secondary ECU. When the VSD system (vehicle) is in the development configuration, only the primary and secondary ECUs may be powered on, and the remaining ECUs in the vehicle may not be powered on. For example, in a battery electric vehicle (BEV), a cockpit domain controller (C-DC) ECU may be selected as the primary ECU, and in a non-BEV, an in-vehicle infotainment (IVI) ECU or an instrument cluster (IC) ECU may be selected as the primary ECU.

[0040] The primary ECU may serve as an access point for a user to access various vehicle functions when developing software for the vehicle. Figure 2 is a block diagram of example elements of primary ECU 200 according to one or more embodiments. As shown in Figure 2, primary ECU 200 may include a root partition 210, a key partition 220, a configuration partition 230, a virtual machine (VM) first partition 240, a VM second partition 250, a VM third partition 260, and a user partition 270.

[0041] The root partition 210 may include an operating system (e.g., a type 1 hypervisor) that runs other systems required for vehicle operation. The key partition 220 may include encryption keys for unlocking each partition of the primary ECU 200. The configuration partition 230 may include configuration data related to the start of each virtual machine in the partitions of the primary ECU 200 (e.g., virtual machines in the VM first partition 240, the VM second partition 250, and the VM third partition 260). The VM first partition may include VMs related to safety-related functions of the vehicle, as well as a real-time operating system (RTOS). The VM second partition 250 may include VMs related to non-safety-related functions, such as IVI multimedia. The VM third partition 260 may include VMs related to software development frameworks, such as Android Auto (registered trademark) and Apple CarPlay (registered trademark). The user partition 270 may include user data (driver's data).

[0042] According to an example embodiment, when the VSD system (vehicle) is in a development configuration, only some of the partitions of the primary ECU may be unlocked for access by user 110 (software developer) to perform software development for the vehicle. For example, in the development configuration, only root partition 210, key partition 220, configuration partition 230, VM second partition 250, VM third partition 260, and user partition 270 may be unlocked. According to an example embodiment, the disk of primary ECU 200 may use full disk encryption, with each partition being separately encrypted with a different encryption key. For example, user partition 270 may be associated with a personal identification number (PIN), and user partition 270 may be unlocked in development mode when user 110 provides the corresponding PIN.

[0043] According to an example embodiment, the primary ECU may be rebooted on demand. According to an example embodiment, the primary ECU may further include a Replay Protected Memory Block (RPMB) and electronic fuses (e-fuses). The contents of the RPMB may be overwritten but not erased. This configuration prevents downgrade attacks (i.e., rollback to an older or vulnerable version) during development. The current version of the software on the vehicle may be stored in the RPMB prior to the start of a development configuration, and the development configuration may not be allowed to write to the RPMB.

[0044] It should be understood that the above is provided for illustrative purposes and is not intended to limit the scope of the present disclosure in any way. In particular, in practice, primary ECU 200 may include more or fewer components than those depicted in FIG. 2 and may be combined in a different manner than depicted in FIG. 2 without departing from the scope of the present disclosure. For example, VM third partition 260 may be divided into two separate partitions, one for Android Auto and one for Apple CarPlay. Furthermore, other ECUs in the vehicle may also include multiple partitions.

[0045] The secondary ECU may act as a RAM disk for the primary ECU. A RAM disk is a non-persistent virtual file system that exists only in memory, and the secondary ECU may be configured to act as the RAM disk for the primary ECU. According to an example embodiment, files that user 110 wants to persist between builds may reside in the memory disk of the secondary ECU. Furthermore, files stored on the memory disk of the secondary ECU may be exported outside of VSD system 120 (e.g., to user 110's device). This configuration allows a primary ECU with non-persistent memory to reserve enough space in memory to run software while minimizing degradation in processing speed.

[0046] The primary ECU and the secondary ECU may be communicatively connected via some kind of interface. According to an exemplary embodiment, the primary ECU and the secondary ECU may be communicatively connected via a high-speed bus such as a Peripheral Component Interconnect (PCI) Express.

[0047] A production configuration of a vehicle may be a configuration of the vehicle in which all subsystems of the vehicle are unlocked for access by a driver to operate the vehicle. In particular, the production configuration may unlock all partitions of all ECUs in the vehicle for access by the driver to allow the driver to operate the vehicle.

[0048] Each of the development and production configurations may be associated with an encryption key, and the development and production configurations may be initiated when the VSD system 120 receives the associated encryption key.

[0049] For example, a driver may possess a physical or digital key containing an asymmetric product encryption key (e.g., elliptic curve cryptography). Such an encryption key may be associated with a production configuration (i.e., a production key), and when the driver provides the production key (i.e., a key for driving and operating a vehicle in a production configuration) to VSD system 120, the vehicle may boot and all subsystems of the vehicle may be unlocked to allow the driver to operate the vehicle. In particular, a hypervisor in root partition 210 of primary ECU 200 may use the production key to unlock key partition 220 of primary ECU 200 to boot and decrypt all keys contained in key partition 220. In other words, the production key can unlock all partitions of primary ECU 200. The hypervisor then decrypts and uses the production configuration of the VM and properly boots all partitions.

[0050] On the other hand, user 110 (a software developer) may possess a physical or digital key containing an asymmetric non-production cryptographic key (e.g., elliptic curve cryptography). Such a cryptographic key may be associated with a development configuration (i.e., a development key), and when user 110 provides VSD system 120 with the development key (i.e., a key for developing vehicle software), only a portion of the vehicle's subsystems may be unlocked. In particular, a hypervisor in root partition 210 of primary ECU 200 may be launched and unlock key partition 220 of primary ECU 200 using the development key to decrypt only a portion of the keys contained in key partition 220 (i.e., keys for unlocking a portion of the partitions of primary ECU 200). In other words, the development key can unlock only a portion of the partitions of primary ECU 200. The hypervisor may then decrypt and use the development configuration for the VM and properly start the VM of the unlocked partition, rendering the entire file system read-only when the VM starts. The development key does not have to unlock partitions related to safety-critical VMs or functions, meaning the vehicle will operate but not be able to change into drive mode.

[0051] In this regard, an encryption key received by the VSD system may be authenticated to determine whether the encryption key received by the VSD system is a development key, a production key, or neither. According to an example embodiment, the received encryption key may be authenticated based on one or more public keys stored in the VSD system's memory. Notably, the development key and production key included in the physical / digital key may be private keys. In this regard, for example, when the physical key is inserted into the vehicle's key slot, an encryption key (i.e., private key) may be generated and send an authentication request to the VSD system, and one or more public keys stored in the VSD system's memory may be used to authenticate the received encryption key. If the received encryption key is associated with any of the one or more public keys stored in the VSD system's memory, the received encryption key may be successfully authenticated and identified.

[0052] If the received encryption key is associated with a public key associated with a development configuration (development public key), the received encryption key may be successfully authenticated and identified as a development key, and the VSD system may initiate the development configuration accordingly. Similarly, if the received encryption key is associated with a public key associated with a production configuration (production public key), the received encryption key may be successfully authenticated and identified as a production key, and the VSD system may initiate the production configuration accordingly. On the other hand, if the received encryption key is not associated with any of the one or more public keys stored in the VSD system's memory, the received encryption key may not be identified as either a development key or a production key and may not be successfully authenticated. Thereafter, the vehicle may not initiate any subsystems.

[0053] 3, example components included in VSD system 120 will be described in accordance with one or more embodiments. Additionally, example operations that VSD system 120 may perform for vehicle development will be described in conjunction with FIGS. 4-7.

[0054] 1, VSD system 120 may interact with users 110. According to an example embodiment, users 110 may include software / application developers who develop software / applications for the vehicle (i.e., VSD system 120 or the vehicle in which VSD system 120 is implemented).

[0055] Furthermore, the user 110 may interact with the VSD system 120 using any means. For example, as described above, when authenticating an encryption key, the user 110 may insert a physical key containing the encryption key into the vehicle's key slot to provide the encryption key to the VSD system 120. In another example, when developing software for a vehicle, the user 110 may interact with the VSD system 120 through a device such as a development kit, a personal computer (PC), or the like, connected to the VSD system 120 via an interface such as a Universal Serial Bus (USB). In this case, the USB port of the IVI may be unlocked in the development configuration. Furthermore, devices connected to the VSD system 120 may be cryptographically authenticated. For example, a development kit may connect to the VSD system 120 via USB using a public key authentication challenge.

[0056] It should be understood that the above is provided for illustrative purposes and is not intended to limit the scope of the present disclosure in any way. In particular, in practice, user 110 may use any means (e.g., digital key, touch sensor, etc.) to provide the encryption key to VSD system 120, and software developers may use any type of device and interface to interact with VSD system 120.

[0057] 3 is a block diagram of example elements of a VSD system 300, according to one or more embodiments. VSD system 300 may correspond to VSD system 120 of FIG. 1, and features associated with VSD system 120 and VSD system 300 are equally applicable to each other unless expressly stated differently.

[0058] As depicted in FIG. 3, VSD system 300 may include at least one communication interface 310, at least one processor 320, at least one input / output component 330, and at least one storage 340; VSD system 300 may include more or fewer components than depicted in FIG. 3 and may be combined in different ways than depicted in FIG. 3 without departing from the scope of the present disclosure.

[0059] Communication interface 310 may include at least one transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that allows components of VSD system 300 to interact with each other and / or with one or more components external to VSD system 300 via connections, such as wired connections, wireless connections, or a combination of wired and wireless connections. For example, communication interface 310 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a USB interface, a Wi-Fi interface, a cellular network interface, etc.

[0060] For example, communication interface 310 may connect processor 320 to storage 340, enabling them to communicate with each other and perform one or more operations. In other examples, communication interface 310 may connect VSD system 300 (or one or more components thereof) to user 110, enabling them to communicate with each other.

[0061] According to one or more embodiments, communication interface 310 may include one or more application programming interfaces (APIs) that enable VSD system 300 (or one or more components thereof) to interact with one or more software applications (e.g., software applications deployed on devices used by user 110).

[0062] Input / output component 330 may include at least one component that allows VSD system 300 to receive information and / or output information. In some embodiments, input / output component 330 may include at least one input component (e.g., a touchscreen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.) and at least one output component (e.g., a display, a speaker, one or more light emitting diodes (LEDs), etc.), which may be separate from one another. Additionally or alternatively, at least one input component may include a sensor (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator) that detects information.

[0063] Storage 340 may include at least one storage medium suitable for storing data, information, and / or computer-executable instructions. According to an example embodiment, storage 340 may include at least one memory storage device, such as random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory), that stores information and / or instructions used by processor 320. Additionally or alternatively, storage 340 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, cartridges, magnetic tape, and / or other types of non-transitory computer-readable media with corresponding drives. Computer-readable media is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0064] According to an example embodiment, storage 340 may be configured to store information such as raw data, metadata, etc. Additionally or alternatively, storage 340 may be configured to store one or more pieces of information associated with one or more operations performed by processor 320. For example, storage 340 may store information defining a sequence of operations to be performed by processor 320 for the development of vehicle software, one or more results of the operations performed by processor 320, etc. Furthermore, storage 340 may store data or information required for the development of vehicle software.

[0065] In some implementations, storage 340 may include multiple storage media, and storage 340 may be configured to store duplicates or copies of at least some of the information on the multiple storage media to provide redundancy and back up the information or associated data. Additionally, storage 340 may store computer-readable or computer-executable instructions that, when executed by one or more processors (e.g., processor 320), cause the one or more processors to perform one or more actions / operations described herein.

[0066] Processor 320 may include at least one processor that may be programmed or configured to perform the functions or operations described herein. For example, processor 320 may be configured to execute computer-executable instructions stored on at least one storage medium or memory storage (e.g., storage 340) to perform one or more actions or operations described herein.

[0067] According to an example embodiment, processor 320 may be configured to receive one or more signals and / or one or more user inputs (e.g., via communications interface 310, via input / output component 330, etc.) that define one or more instructions for performing one or more operations. Furthermore, processor 320 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 320 may include at least one of a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other types of processing or computing elements.

[0068] According to an example embodiment, processor 320 may be configured to collect, extract, and / or receive one or more pieces of information (e.g., in the form of signals or data) from user 110 and process the received one or more pieces of information to develop vehicle software.

[0069] The number and combination of components depicted in Figure 3 are provided as an example. In practice, VSD system 300 may include additional components, fewer components, different components, or components arranged differently from those depicted in Figure 3. Additionally or alternatively, a set of components (e.g., one or more components) of a VSD system may perform one or more functions that are described as being performed by other sets of components of VSD system 300.

[0070] Some example operations that may be performed by processor 320 are described below with reference to FIGS. [Example of Operation for Vehicle Software Development in This Disclosure]

[0071] Some example operations that can be performed by the VSD system of the present disclosure are described below with reference to FIGS.

[0072] 4 is a flow diagram of an example vehicle software development method 400, according to one or more embodiments. One or more operations of method 400 may be performed by at least one processor (e.g., processor 320) of the VSD system.

[0073] 4, at operation S410, the at least one processor may be configured to receive an encryption key. According to an example embodiment, the encryption key may include a development key. According to an example embodiment, the encryption key may be a private key. According to an example embodiment, the encryption key may be received from a user. For example, the user may insert a physical key containing the encryption key into a key slot of the vehicle. The method proceeds to operation S420.

[0074] In operation S420, the at least one processor may be configured to authenticate the received encryption key. According to an example embodiment, the received encryption key may be authenticated based on one or more public keys stored in memory of the VSD system. The method then proceeds to operation S430.

[0075] In operation S430, the at least one processor may be configured to initiate a development configuration of the vehicle in response to successful authentication of the received encryption key. According to an example embodiment, the development configuration of the vehicle may refer to a configuration of the vehicle in which only some of the vehicle's subsystems are unlocked for user access to perform software development for the vehicle. According to an example embodiment, the development configuration may include a primary vehicle Electronic Control Unit (ECU) and a secondary vehicle ECU, where the primary ECU may include multiple partitions, and the secondary ECU may act as a RAM disk for the primary ECU. According to an example embodiment, the multiple partitions of the primary ECU may include one or more of a partition including a hypervisor, a partition including encrypted keys, a partition including configuration data, a partition including virtual machines related to safety features of the vehicle, a partition including virtual machines related to non-safety features of the vehicle, a partition including virtual machines related to a software development framework, and a partition including user data.

[0076] According to an example embodiment, the primary ECU and the secondary ECU may be communicatively coupled via an interface such as a Peripheral Component Interconnect (PCI) Express. According to an example embodiment, the received encryption key may be successfully authenticated if the received encryption key is associated with a development public key. The development public key may be stored in a memory of the VSD system and associated with a development configuration.

[0077] As a result of the above process, a user can directly develop vehicle software / applications without the need for specialized hardware and tools. Furthermore, because the development setup is initiated after successful authentication of the cryptographic key and only some of the vehicle's subsystems are unlocked for the user's access to perform vehicle software development on the vehicle, the above process prevents harmful access to the vehicle that would compromise the safety of the vehicle. The method then proceeds to operation S440.

[0078] In operation S440, the at least one processor may be configured to terminate the development configuration and erase the memory of the secondary ECU in response to detecting the erasure of the received encryption key from the vehicle. In particular, according to example embodiments, to detect the erasure of the received encryption key from the vehicle, the at least one processor may be configured to monitor the received encryption key after the development configuration of the vehicle is initiated. For example, a user may complete development of the vehicle software while the vehicle is in the development configuration, and then the user may remove the physical key containing the encryption key from the vehicle's key slot. Then, in response to detecting the erasure of the received encryption key from the vehicle, the development configuration may be terminated and the memory of the secondary ECU may be erased. According to example embodiments, the development configuration may be terminated by powering off the primary ECU and the secondary ECU.

[0079] Upon performance of act S440, method 400 may end or abort. Alternatively, method 400 may return to act S410, and the at least one processor may be configured to repeatedly receive the encryption key (act S410), authenticate the received encryption key (act S420), initiate the development configuration (act S430), and terminate the development configuration (act S440) at least a predetermined number of times. For example, the at least one processor may continuously (or periodically) receive more encryption keys and resume receiving the encryption key (act S410), authenticating the received encryption key (act S420), initiate the development configuration (act S430), and terminate the development configuration (act S440). [Example of operation for starting development settings in this disclosure]

[0080] In the following, an example of operations for starting the development configuration of a vehicle will be described with reference to FIG.

[0081] 5 is a flow diagram of an example method 500 for initiating a development configuration of a vehicle, according to one or more embodiments. One or more operations of method 500 may be part of operation S430 in method 400 and may be performed by at least one processor (e.g., processor 320) of the VSD system.

[0082] As shown in FIG. 5 , in operation S510, the at least one processor may be configured to select a primary ECU and a secondary ECU. The primary ECU and the secondary ECU may be selected based on a predetermined configuration. According to an example embodiment, the predetermined configuration file may identify one ECU from the plurality of ECUs in the vehicle as the primary ECU and another ECU from the plurality of ECUs in the vehicle as the secondary ECU. The primary ECU and the secondary ECU may then be selected from the plurality of ECUs in the vehicle based on the predetermined configuration file. According to an example embodiment, the predetermined configuration file may be predefined by a vehicle manufacturer or the like and stored in a memory of the VSD system. The method then proceeds to operation S520.

[0083] In operation S520, the at least one processor may be configured to boot the selected primary ECU and the selected secondary ECU. According to an example embodiment, the primary ECU may be configured to boot first, and then send a command to the secondary ECU. The command may instruct the secondary ECU to boot using the memory as a RAM disk. According to an example embodiment, the secondary ECU may boot using the memory as a RAM disk without unlocking any physical partitions. The method then proceeds to operation S530.

[0084] In operation S530, the at least one processor may be configured to unlock some of the partitions of the primary ECU. According to an example embodiment, the unlocked some of the partitions of the primary ECU may include one or more of a partition containing a virtual machine for non-safety functions of the vehicle, a partition containing a virtual machine for a software development framework, and a partition containing user data. According to an example embodiment, the unlocked some of the partitions of the primary ECU may be read-only. The method then proceeds to operation S540.

[0085] In operation S540, the at least one processor may be configured to host a development environment on the secondary ECU. According to an example embodiment, the development environment may be established on the secondary ECU by loading developer tools into a memory of the secondary ECU to create the development environment. An example operation for hosting a development environment on the secondary ECU is described below with reference to Figures 6A and 6B. [Example of operation for providing a development environment in a secondary ECU in this disclosure]

[0086] 6A is a flow diagram of an example method 600A for providing a development environment on a secondary ECU, according to one or more embodiments. One or more operations of method 600A may be part of operation S540 in method 500 and may be performed by at least one processor (e.g., processor 320) of the VSD system.

[0087] 6A , in operation S610A, at least one processor may be configured to receive one or more instructions to preserve functionality of the primary ECU. The received one or more instructions may be received from a user in a development environment (i.e., provided on the secondary ECU). According to an example embodiment, the one or more instructions may be received from a user via a development kit connected to the VSD system using a USB interface. According to an example embodiment, the one or more instructions may include a write system call.

[0088] According to example embodiments, the functionality of the primary ECU may be a new functionality that does not currently exist in the primary ECU. According to example embodiments, the functionality of the primary ECU may be a modified version of a functionality that currently exists in the primary ECU.

[0089] For example, a user may request to modify a function of the primary ECU for purposes of vehicle software development and / or testing. In this case, because the unlocked partition of the primary ECU is read-only, the user may modify the function of the primary ECU and store this modified function of the primary ECU in the secondary ECU. Then, when the user desires access to this modified function, the VSD system may access the modified function stored in the secondary ECU instead of the unmodified function stored in the primary ECU (see below regarding method 600B). The method then proceeds to operation S620A.

[0090] In act S620A, the at least one processor may be configured to store functionality in a secondary ECU.

[0091] According to an example embodiment, the at least one processor may further update the memory stack of the primary ECU to include a reference to the function of the primary ECU stored in the secondary ECU. Then, for example, any access to the function of the primary ECU may be redirected to the modified function of the primary ECU stored in the secondary ECU instead of the unmodified function stored in the primary ECU. The method then proceeds to operation S630A.

[0092] In operation S630A, the at least one processor may be configured to export the stored functionality to a device. According to an example embodiment, the device may include a device external to the VSD system.

[0093] For example, once a user has completed development and / or testing of vehicle software in a vehicle using the primary ECU's functions stored in the secondary ECU, the VSD system may export the stored functions of the primary ECU to an external device (e.g., a development kit, a development PC, etc.) so that the user can further develop the vehicle software.

[0094] 6B is a flow diagram of an example method 600B for providing a development environment on a secondary ECU, according to one or more embodiments. One or more operations of method 600B may be part of operation S540 in method 500 and may be performed by at least one processor (e.g., processor 320) of the VSD system.

[0095] 6B, in operation S610B, at least one processor may be configured to receive one or more instructions to access functionality of the primary ECU. The received one or more instructions may be received from a user in a development environment (i.e., provided on the secondary ECU). According to an example embodiment, the one or more instructions may be received from a user via a development kit connected to the VSD system using a USB interface. According to an example embodiment, the one or more instructions may include a write system call.

[0096] According to an example embodiment, the primary ECU may be associated with multiple vehicle functions, and the multiple functions may be accessed by a user via a development environment and unlocked portions of the primary ECU's partitions. The method then proceeds to operation S620B.

[0097] In act S620B, the at least one processor may be configured to determine whether the functionality is stored in the secondary ECU.

[0098] In particular, as described above with respect to operation S620A of method 600A, a user may request to modify and / or add functionality to the primary ECU for development and / or testing of vehicle software in the vehicle, and such functionality may be stored in the secondary ECU. In this case, in operation S620B, the at least one processor may be configured to determine whether the functionality that the user wishes to access in operation S610B is stored in the secondary ECU (i.e., whether the functionality that the user wishes to access in operation S610B is the new / modified functionality stored in the secondary ECU or the original / unmodified functionality stored in the primary ECU).

[0099] Then, in response to determining that the function is stored in the secondary ECU, the at least one processor determines in operation S610B that the function the user wishes to access is the new / modified function stored in the secondary ECU, and the method proceeds to operation S630B. Alternatively, in response to determining that the function is not stored in the secondary ECU, the at least one processor determines in operation S610B that the function the user wishes to access is the original / unmodified function stored in the primary ECU, and the method proceeds to operation S650B.

[0100] In operation S630B, the at least one processor may be configured to access functions stored in the secondary ECU. Similarly, in operation S650B, the at least one processor may be configured to access functions stored in the primary ECU. The method then proceeds to operation S640B.

[0101] In operation S640B, the at least one processor may be configured to send the results of the access to the feature to the development environment. According to an example embodiment, the results of the access to the feature may be obtained from the primary ECU. A user may then receive feedback for developing and / or testing the vehicle software in the vehicle.

[0102] According to an example embodiment, one or more operations from methods 600A and 600B may be combined.

[0103] For example, at least one processor may receive one or more instructions to save functionality of the primary ECU, where operations S610A and S620A may be performed. Thereafter, at least one processor may receive one or more instructions to access functionality of the primary ECU, where operations S610A through S640B may be performed before operation S630A is performed. [Example of vehicle software development flow in this disclosure]

[0104] FIG. 7 is a diagram illustrating example interactions between a primary ECU, a secondary ECU, and user equipment in accordance with one or more embodiments.

[0105] 7, a vehicle's Advanced Driver Assistance System (ADAS) Domain Controller (A-DC) ECU 710 may correspond to a secondary ECU and may include a QNX operating system 711 and memory 712. The secondary ECU's memory 712 may act as a RAM disk for the primary ECU and may provide a development environment.

[0106] Additionally, the vehicle's Cockpit Area Controller (C-DC) ECU 720 may correspond to the primary ECU. Additionally, the C-DC ECU 720 may include a QNX operating system 721, a Qualcomm Trusted Execution Environment (QTEE) 722, a MicroController Unit (MCU) 723, an Advanced Reduced Instruction Set Computer Machine (ARM) processor R-core 724, and an ARM processor A-core 725. The disk of the A-core 725 may be read-only in a development configuration.

[0107] The C-DC ECU 720 may be communicatively connected to the A-DC ECU 710 via PCI-Express, Ethernet, or CAN FD (Controller Area Network with Flexible Data Rate). In particular, communication between the C-DC ECU 720 and the A-DC ECU 710 via PCI-Express may be managed by an R-Core 724. Additionally, the C-DC ECU 720 may be communicatively connected to a user device 730 via a USB connection.

[0108] An example of a vehicle software development flow may begin with a user inserting a physical key into the vehicle's key slot. Once inserted and activated, the private key in the physical key generates a challenge (authentication string) and sends it to the vehicle. The value is authenticated by the public key stored in the e-fuse. Here, the private key may be a development key.

[0109] The development public key is then used to decrypt or unlock the partitions of the primary ECU. The development public key only unlocks some of the partitions as read-only and cannot unlock any of the safety-related partitions. A Hardware Security Module (HSM) or secure partition may be used to store the keys. The QNX721 is then notified of the ECU acting as a RAM disk (i.e., the secondary ECU / A-DC ECU710), and the A-DC ECU710 begins booting.

[0110] The developer tools are loaded from the memory of the A-DC ECU 710 and a development environment is created. Once the development environment is created, the development kit uses a challenge signed with a public key to access the development environment via a user device 730 connected to the C-DC ECU 720 using a USB connection.

[0111] The user can now authenticate the signature on user equipment 730 and begin developing / testing the vehicle software. In particular, the user may use the RAM disk for data retention and for calls and responses to and from functions in C-DC ECU 720. It should be understood that functions accessible by the user are not safety-critical. Furthermore, because functions are read-only, the user may modify functions or add new functions by writing the modified / new functions to memory 712 (i.e., RAM disk). Once the modified / new functions are written, A-DC ECU 710 may update the memory stack of C-DC ECU 720 to include references to the modified / new functions so that calls to the functions are forwarded to the new modified / new functions.

[0112] When the user completes development / testing, the user can save the contents of memory 712 to the user equipment 730. The user equipment 730 can then be disconnected and the development keys erased. Subsequently, the memory 712 is erased and the vehicle is turned off. The user can then obtain verification and certification using the contents of memory 712 (e.g., developed code), which will eventually go to the vehicle. Various aspects of the embodiment

[0113] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the practice to the precise form disclosed. Modifications and variations are possible in light of the above disclosure and may be acquired from practice of the implementations.

[0114] Some embodiments relate to systems, methods, and / or computer-readable media at the most technically detailed level of integration possible. Furthermore, one or more of the aforementioned components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a non-transitory computer-readable medium having computer-readable program instructions recorded thereon for causing a processor to perform an operation.

[0115] A computer-readable storage medium may be any tangible device that can hold and store instructions for use by an instruction-execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM) or flash memory, Static Random Access Memory (SRAM), Compact Disc Read-Only Memory (CD-DOM), Digital Versatile Disk (DVD), Memory Stick®, mechanically encoded devices such as punch cards or groove ridge structures having instructions recorded thereon, and suitable combinations of the above. Computer-readable storage device, as used herein, is not to be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal through an electrical wire.

[0116] The computer-readable program instructions described in this disclosure may be downloaded from a computer-readable storage medium to each computing / processing device, or may be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0117] The computer-readable program code / instructions for performing operations may be assembler instructions, Instruction-Set-Architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state configuration data, configuration data for integrated circuits, or other source or object code written in a combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as "C" or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software product, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer by any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made by an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions using state information of the computer-readable program instructions to specialize the electronic circuitry to perform aspects or operations.

[0118] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other data processing means, which, through the processor of the computer or other programmable data processing means, creates means for implementing the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium that causes the computer, programmable data processing means, and / or other device to function in a particular manner, such that the computer-readable storage medium storing the instructions is part of a manufacturing process that includes instructions that implement aspects of the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams.

[0119] The computer readable program instructions may be loaded into a computer, other programmable data processing means, or other device to create a computer-implemented process such that the computer, other programmable data processing means, or other device implements the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams, such that a series of operational steps are executed by the computer, other programmable data processing means, or other device.

[0120] The flowcharts and block diagrams in the figures represent the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media in various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a microservice module, segment, or portion of instructions, including one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include more, fewer, different, or differently combined blocks than those shown in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a special-purpose hardware-based system that performs the specified functions or executes a combination of special-purpose hardware and computer instructions.

[0121] It will be apparent that the systems and / or methods described herein may be implemented as different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software used to implement these systems and / or methods is not a limitation of the implementation. As such, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods described herein.

[0122] It will be appreciated that numerous modifications and variations of the present disclosure are possible in light of the above teachings. Within the scope of the supplemental provisions, the present disclosure may be practiced otherwise than as expressly described herein.

Claims

1. a storage device storing computer-executable instructions; at least one processor communicatively coupled to the storage device; At least one processor Receive the encryption key, authenticating the received encryption key; In response to successful authentication of the received encryption key, initiate a development configuration of the vehicle, the development configuration including a primary electronic control unit (ECU) of the vehicle including a plurality of partitions and a secondary ECU of the vehicle acting as a RAM disk for the primary ECU; In response to detection of deletion of the received encryption key from the vehicle, the development setting is terminated and the memory of the secondary ECU is erased. A system configured to execute instructions.

2. The system of claim 1 , wherein the at least one processor is configured to execute instructions to initiate the development configuration by selecting the primary ECU and the secondary ECU based on a predetermined configuration file.

3. 3. The system according to claim 1, wherein the primary ECU and the secondary ECU are communicatively connected via a PCI Express interface.

4. The system of claim 1 or 2, wherein the at least one processor is configured to execute instructions to initiate the development configuration by unlocking portions of the plurality of partitions of the primary ECU.

5. 5. The system of claim 4, wherein the unlocked portions of the plurality of partitions of the primary ECU include at least one of a partition containing a virtual machine for non-safety related functions of the vehicle, a partition containing a virtual machine for a software development framework, and a partition containing user data.

6. The system of claim 5 , wherein the at least one processor is configured to execute instructions that initiate the development configuration by providing a development environment on the secondary ECU.

7. the primary ECU is associated with a plurality of functions of the vehicle; the plurality of functions are accessed by a user via the development environment and the unlocked portions of the plurality of partitions of the primary ECU; The system of claim 6.

8. The at least one processor: receiving one or more instructions from a user to store functionality of the primary ECU in the development environment; storing the function in the secondary ECU; exporting the saved functions to a device; and executing instructions to establish the development environment by The system of claim 6.

9. The at least one processor: receiving one or more instructions from a user in the development environment to access functionality of the primary ECU; determining whether the function is stored in the secondary ECU; In response to determining that the function is stored in the secondary ECU, accessing the function stored in the secondary ECU; accessing the function stored in the primary ECU in response to determining that the function is not stored in the secondary ECU; sending a result of accessing the function to the development environment; and executing instructions to establish the development environment by The system of claim 6.

10. receiving the encryption key; authenticating the received encryption key; In response to successful authentication of the received encryption key, initiating a development configuration of a vehicle, the development configuration including a primary ECU of the vehicle including a plurality of partitions and a secondary ECU acting as a RAM disk for the primary ECU; In response to detection of deletion of the received encryption key from the vehicle, terminating the development setting and erasing the memory of the secondary ECU; 2. A method executed by at least one processor, comprising:

11. The method of claim 10 , wherein initiating the development configuration includes selecting the primary ECU and the secondary ECU based on a predetermined configuration file.

12. The method according to claim 10 or 11, wherein the primary ECU and the secondary ECU are communicatively connected via a PCI Express interface.

13. The method of claim 10 or 11, wherein initiating the development configuration includes unlocking a portion of a plurality of partitions of the primary ECU.

14. 14. The method of claim 13, wherein the unlocked portions of the plurality of partitions of the primary ECU include at least one of a partition containing a virtual machine for non-safety related functions of the vehicle, a partition containing a virtual machine for a software development framework, and a partition containing user data.

15. The method of claim 14 , wherein initiating the development configuration further comprises providing a development environment on the secondary ECU.

16. the primary ECU is associated with a plurality of functions of the vehicle; the plurality of functions are accessed by a user via the development environment and the unlocked portions of the plurality of partitions of the primary ECU; 16. The method of claim 15.

17. Providing the development environment includes: receiving one or more instructions from a user to save functionality of the primary ECU in the development environment; storing the function in the secondary ECU; exporting the saved functions to a device; 16. The method of claim 15, comprising:

18. Providing the development environment includes: receiving one or more instructions from a user in the development environment to access functionality of the primary ECU; determining whether the function is stored in the secondary ECU; accessing the function stored in the secondary ECU in response to determining that the function is stored in the secondary ECU; accessing the function stored in the primary ECU in response to determining that the function is not stored in the secondary ECU; sending a result of accessing the function to the development environment; 16. The method of claim 15, comprising:

19. At least one processor receiving the encryption key; authenticating the received encryption key; In response to successful authentication of the received encryption key, initiating a development configuration of a vehicle, the development configuration including a primary ECU of the vehicle including a plurality of partitions and a secondary ECU acting as a RAM disk for the primary ECU; In response to detection of deletion of the received encryption key from the vehicle, terminating the development setting and erasing the memory of the secondary ECU; A computer program for causing a method comprising:

20. 20. The computer program product of claim 19, wherein initiating the development configuration includes selecting the primary ECU and the secondary ECU based on a predetermined configuration file.

Images