Uniform software assembly packaging

Abstract

To provide packaging for a uniform software assembly.SOLUTION: Packaging for a uniform software assembly is performed by testing a device software assembly according to a test script included in a device software assembly to obtain test result information, and generating a device package from the device software assembly, the generated device package enables installing and verifying software on a target hardware element of a vehicle architecture specification included in the device software assembly. The generated device package contains: multiple binaries each corresponding to one of multiple program packages included in the device software assembly and build scripts included in the device software assembly; metadata including debug information; a description of the generated device package; and the test result information.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] A vehicle system consists of many ECUs (Electronic Controller Units), each with its own software stack. The integration of many ECUs is performed using software code, software construction tools, and software construction methods. Summary of the Invention

[0002] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of discussion. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a schematic diagram of a software assembly for uniform software assembly packaging in accordance with at least some embodiments of the present disclosure. [Figure 2] FIG. 2 is an operational flow for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure. [Figure 3] FIG. 3 is an operational flow for package generation according to at least some embodiments of the present disclosure. [Figure 4] FIG. 4 is a schematic diagram of a generated package for packaging a uniform software assembly, according to at least some embodiments of the present disclosure. [Figure 5] FIG. 5 is a block diagram of a hardware configuration for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0004] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific examples of components, values, operations, materials, arrangements, etc. are described below to simplify the disclosure. These are, of course, merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are contemplated. In addition, the disclosure may repeat reference numerals and / or letters in various examples. This repetition is for simplicity and clarity and does not, in itself, dictate a relationship between the various aspects and / or configurations discussed.

[0005] As the level of complexity of vehicle systems increases, the construction tools required to assemble the vehicle systems become more specialized. However, the software construction tools and software construction methods differ for the software code among the various ECUs in a vehicle system. The software code for a particular ECU uses the software construction tools and software construction methods beneficial to that particular ECU, regardless of the other ECUs and their corresponding software code.

[0006] The software assembly is uniformly packaged by testing the device software assembly according to at least one test script included in the device software assembly to generate test result information, and generating a device package from the device software assembly. The generated device package is executable to install and verify the software on target hardware elements of the vehicle architecture specification included in the device software assembly. The generated device package includes a plurality of binaries, each binary included in the device software assembly and corresponding to one of at least one operating system package, at least one middleware package, and at least one application package and a build script included in the device software assembly, metadata including debug information, a description of the generated device package, and test result information.

[0007] Uniform packaging of software assemblies enables the automation of building, packaging, testing, and deployment of software stacks for each ECU and vehicle system.

[0008] The inventors compare software assemblies in at least some embodiments to high-level mechanical assemblies that combine a set of low-level parts (single parts and / or other subassemblies). Generating such a mechanical assembly may require somewhat more information than a simple list of the low-level parts. For example, the engine and transmission of a powertrain system may be connected via two mechanical interfaces: a drive shaft for power distribution and a bolt pattern for aligning and fastening the two subassemblies.

[0009] Such mechanical assemblies not only require a parts list, but also methods and setup operations for integrating the parts into higher level assemblies. The tools themselves are also parts maintained in a Manufacturing Bill of Materials (MBOM). At least some embodiments are similar in that software development tools are software parts, and software parts are part of a Software Bill of Materials (SBOM).

[0010] In at least some embodiments, a software part is a software component that plays a dedicated role in an integrated system. Like its hardware counterpart, a software part, in at least some embodiments, comprises an assembly of other software parts. In at least some embodiments, a software part refers to a collection of source code, i.e., a package into which the source code is bundled, where the source code is compiled into an executable binary.

[0011] In at least some embodiments, a software assembly is a specialized software component responsible for configuring a system by integrating a set of other software components. In at least some embodiments, software components become a software assembly when integrated, where multiple software units are assembled either manually or through scripting. In at least some embodiments, when a software assembly undergoes an automated integration operation, the software assembly combines its own software components and software components based on their dependencies to form a larger assembly.

[0012] 1 is a schematic diagram of a software assembly for uniform software assembly packaging according to at least some embodiments of the present disclosure. Software assembly 100 includes a vehicle architecture specification 102, a target hardware element identifier 103, a communication specification 104, an operating system package 106, a middleware package 107, an application package 108, a build script 110, a binary code generation model 111, a test script 113, and an ECU emulation model 114.

[0013] In at least some embodiments, software assembly 100 integrates software components. In at least some embodiments, software assembly 100 includes the software components necessary to package a uniform software assembly. In at least some embodiments, software assembly 100 is configured to integrate various components and manage their interactions to achieve a desired functionality. In at least some embodiments, software assembly 100 interacts with the software components and coordinates the functionality of specific software components to generate a uniform software assembly package. In at least some embodiments, software assembly 100 is a software project within a version control system, such as Git®.

[0014] Vehicle architecture specification 102 includes target hardware element identifiers 103 and communication specifications 104. In at least some embodiments, vehicle architecture specification 102 defines a vehicle hardware and software architecture that guides the software assembly process. In at least some embodiments, vehicle architecture specification 102 is configured to specify requirements and constraints for software to be installed on the vehicle's hardware elements. In at least some embodiments, vehicle architecture specification 102 interacts with software assembly 100 and target hardware element identifiers 103 to ensure the software is compatible with the vehicle's hardware. In at least some embodiments, vehicle architecture specification 102 is a document or digital file that details the vehicle's hardware and software specifications. In at least some embodiments, vehicle architecture specification 102 is of a type used in the design and development of vehicle systems. In at least some embodiments, vehicle architecture specification 102 is used by device software assemblies as a reference architecture that the device software assemblies must implement. In at least some embodiments, the reference architecture indicates other dependencies and provides variation and configuration information. In at least some embodiments, the vehicle architecture specification includes an acceptable version of at least one operating system package.

[0015] The target hardware element identifier 103 is part of the vehicle architecture specification 102. In at least some embodiments, the target hardware element identifier 103 interacts with the software assembly 100 to guide the installation of the software on the correct hardware element. In at least some embodiments, the target hardware element identifier 103 is configured to identify a specific hardware element in the vehicle on which the software is to be installed. In at least some embodiments, the target hardware element identifier 103 is configured to accurately identify the target hardware element based on the vehicle architecture specification. In at least some embodiments, the target hardware element identifier 103 is a unique identifier or a hardware address. In at least some embodiments, the target hardware element is an ECU in the vehicle architecture specification. In at least some embodiments, the device software assembly is responsible for implementing one of the ECUs listed in the vehicle architecture. In at least some embodiments, the part number of the device software assembly must match one of the devices in the vehicle architecture. In at least some embodiments, the device software assembly provides a standard tool for extracting a matching device definition file associated with the device software assembly. In at least some embodiments, if no match is found, the device software assembly is invalid and must be modified or deleted.

[0016] Communication specification 104 is part of vehicle architecture specification 102. In at least some embodiments, communication specification 104 interacts with software assemblies to enable the software to communicate effectively within the vehicle's systems. In at least some embodiments, communication specification 104 is configured to define communication protocols and standards used in the vehicle's systems. In at least some embodiments, communication specification 104 is configured to specify communication protocols for data exchange between different hardware elements within the vehicle. In at least some embodiments, communication specification 104 is a technical document detailing communication protocols and standards. In at least some embodiments, communication specification 104 is of a type used in the design and development of communication systems in vehicles. In at least some embodiments, the vehicle architecture specification includes a Controller Area Network (CAN) communication specification. In at least some embodiments, the vehicle architecture specification includes a Local Area Network (LAN) communication specification.

[0017] Operating system package 106 is part of software assembly 100. In at least some embodiments, operating system package 106 interacts with software assembly 100 and target hardware element identifiers 103 to install an operating system on the correct hardware element. In at least some embodiments, operating system package 106 is configured to provide the operating system required for software to run on the vehicle's hardware. In at least some embodiments, operating system package 106 is configured to install and manage an operating system on the target hardware element. In at least some embodiments, operating system package 106 interacts with software assembly 100 and target hardware element identifiers 103 to install the operating system on the correct hardware element. In at least some embodiments, operating system package 106 is a disk image or an installation package. In at least some embodiments, operating system package 106 is a LINUX® operating system, such as DEBIAN®. In at least some embodiments, as specified in vehicle architecture specification 102, every hardware target of an ECU requires a specific operating system, which is also a software component defined by a device definition in vehicle architecture specification 102. In at least some embodiments, the device software assembly must verify that its dependencies on various operating system software components are as defined by the vehicle architecture specification 102 and then maintain the specific versions it uses. In at least some embodiments, the vehicle architecture specification 102 may also define acceptable version ranges to prevent updating the operating system version without authorization.In at least some embodiments, all supported operating systems are considered by the build or packaging process of software components for device integration and are considered as "build-time" change points for hardware targets.

[0018] Middleware package 107 is part of software assembly 100. In at least some embodiments, middleware package 107 interacts with software assembly 100, operating system package 106, and application package 108 to ensure seamless interaction between different software components. In at least some embodiments, middleware package 107 is configured to provide the middleware necessary for software to interact with the operating system and other software. In at least some embodiments, middleware package 107 is configured to install and manage the middleware on target hardware elements. In at least some embodiments, middleware package 107 is a library or framework. In at least some embodiments, middleware package 107 is of a type used in software development and systems integration. In at least some embodiments, vehicle architecture specification 102 defines the middleware software components to use. In at least some embodiments, similar to operating system package 106, when multiple middleware packages are used, the middleware packages are also considered “build-time” change points for the hardware target.

[0019] Application package 108 is part of software assembly 100. In at least some embodiments, application package 108 is configured to provide application software to be installed on a vehicle system. In at least some embodiments, application package 108 is configured to install and manage the application software on target hardware elements. In at least some embodiments, application package 108 interacts with software assembly 100, operating system package 106, and middleware package 107 to ensure that the application software operates correctly. In at least some embodiments, application package 108 is a source code file or an installation script. In at least some embodiments, vehicle architecture specification 102 defines the applications to be allocated to the target hardware. In at least some embodiments, device software assembly 100 is then responsible for combining the application with the middleware and operating system into a set of coherent and coherent binaries that are packaged together.

[0020] Build script 110 is part of software assembly 100. In at least some embodiments, build script 110 is configured to automate the process of building a binary from software assembly 100. In at least some embodiments, build script 110 is configured to compile and link software components to generate a binary. In at least some embodiments, build script 110 interacts with all software components in software assembly 100 to build the binary. In at least some embodiments, build script 110 is a Makefile or a script written in a scripting language such as Python or Bash. In at least some embodiments, build script 110 is of a type used in software development and build automation.

[0021] Binary code generation model 111 is part of software assembly 100. In at least some embodiments, device software assembly further includes model 111 configured to generate binary code. In at least some embodiments, binary code generation model 111 is configured to generate binary code from software components. In at least some embodiments, binary code generation model 111 is configured to convert software components, such as operating system package 106, middleware package 107, application package 108, and build script 110, into binary code that can be executed to install the software on target hardware elements. In at least some embodiments, binary code generation model 111 is a compiler or transpiler. In at least some embodiments, in addition to packaging a uniform software assembly, binary code generation model 111 is used for software development and code generation. In at least some embodiments, logic for some classical ECUs is implemented using Simulink® models. In at least some embodiments, vehicle architecture specification 102 specifies the software components in which the Simulink® models are implemented. In at least some embodiments, the device software assembly is configured to process the Simulink® model to generate code for the application being built and, in combination with the operating system and middleware, generate official binaries for the target hardware.

[0022] Test scripts 113 are part of software assembly 100. In at least some embodiments, test scripts 113 are configured to automate testing of device software assemblies. In at least some embodiments, test scripts 113 are configured to execute test cases and generate test result information. In at least some embodiments, test scripts 113 interact with software assembly 100 and ECU emulated model 114 to test the software. In at least some embodiments, test scripts 113 are scripts written in a scripting language such as Python or Bash, or configuration files for a test framework such as JUnit or PyTest. In at least some embodiments, test scripts 113 are of a type used in software testing and quality assurance. In at least some embodiments, at least one test script 113 is configured to interact with a vehicle simulation. In at least some embodiments, test scripts 113 are system test software components that define test cases and enable engineers to develop custom test step implementations. In at least some embodiments, test scripts 113 include test steps that may rely on system test libraries for interfacing with a test rig. In at least some embodiments, test script 113 includes a custom test step that analyzes logs after a test rig runs. In at least some embodiments, test script 113 defines a test environment that references a particular test rig runtime configuration, such as an output package of a test rig configuration software component.

[0023] An ECU (Electronic Control Unit) emulation model 114 is part of software assembly 100. In at least some embodiments, the device software assembly further includes a model configured to emulate an adjacent ECU. In at least some embodiments, ECU emulation model 114 is configured to emulate an adjacent ECU for testing purposes. In at least some embodiments, ECU emulation model 114 is configured to mimic the behavior of a real ECU to provide a realistic testing environment. In at least some embodiments, ECU emulation model 114 interacts with test scripts 113 to provide a realistic testing environment. In at least some embodiments, ECU emulation model 114 is a software model or a hardware-in-the-loop simulator. In at least some embodiments, ECU emulation model 114 is of a type used in hardware emulation and testing. In at least some embodiments, ECU emulation model 114 includes a lightweight model of an ECU that is the subject of the device software assembly. In at least some embodiments, the lightweight model may implement basic or complete logic for use in testing adjacent ECUs by simulating the environment in which the ECUs reside and respond.

[0024] 2 is an operational flow for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure. In at least some embodiments, the operational flow provides a method for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure. In at least some embodiments, the method is performed by a controller of an apparatus, such as controller 562 of apparatus 560 of FIG. 5 described below.

[0025] In S220, the control unit, or a portion thereof (section), tests the software assembly. In at least some embodiments, the control unit tests the device software assembly according to at least one test script included in the device software assembly to obtain test result information. In at least some embodiments, the control unit tests the vehicle software assembly according to at least one vehicle test script included in the vehicle software assembly to generate vehicle test result information. In at least some embodiments, the control unit executes at least one test script included in the device software assembly. In at least some embodiments, the control unit performs this operation when the software assembly and test script are available. In at least some embodiments, the control unit generates test result information as a result of this operation. In at least some embodiments, the control unit automatically verifies each device by executing a series of system tests organized through a test plan in a test script, such as test script 113. In at least some embodiments, the control unit automatically verifies each vehicle configuration by executing a series of system tests organized through a test plan in a test script, such as test script 113.

[0026] At S222, the controller, or a portion thereof, obtains test result information. In at least some embodiments, the controller collects output from the test script execution. In at least some embodiments, the controller collects output from the test script execution in response to successful completion of the software assembly test. In at least some embodiments, the controller provides insight into the performance and functionality of the software assembly through the test result information. In at least some embodiments, the test result information provides data for determining whether the software assembly is valid and ready for packaging.

[0027] At S224, the controller, or a portion thereof, determines whether the software assembly is valid. In response to the software assembly not being valid, the operational flow ends. In response to the software assembly being valid, the operational flow proceeds at S226 to generate a package from the software assembly. In at least some embodiments, the controller evaluates test result information to determine whether the software assembly is valid during operation S224. In at least some embodiments, the controller evaluates the test result information in response to the test result information becoming available. In at least some embodiments, the controller ensures that only valid and functional software assemblies are packaged.

[0028] At S226, the controller, or a portion thereof, generates a package from the software assembly. In at least some embodiments, the controller generates an equipment package from the equipment software assembly, the generated equipment package being executable to install and verify software on target hardware elements of the vehicle architecture specification included in the equipment software assembly. In at least some embodiments, the controller generates a vehicle package from the vehicle software assembly, the vehicle package being executable to install and verify software on each hardware element including the target elements of the vehicle architecture specification. In at least some embodiments, the controller generates an equipment package from the verified software assembly. In at least some embodiments, the controller generates an executable package capable of installing and verifying the software on the target hardware elements. In at least some embodiments, the controller generates the equipment package in response to verifying the software assembly. In at least some embodiments, the generating includes building multiple binaries. In at least some embodiments, the controller includes the binaries, build scripts, metadata, descriptions, and test result information in the generated equipment package. In at least some embodiments, the controller packages the verified software assembly into a deployable and executable format.

[0029] 3 is an operational flow for package generation according to at least some embodiments of the present disclosure. In at least some embodiments, the operational flow provides a method of package generation according to at least some embodiments of the present disclosure. In at least some embodiments, the method is performed by a controller of an apparatus, such as controller 562 of apparatus 560 of FIG. 5 described below.

[0030] At S330, the controller, or a portion thereof, builds a binary file from the source code. In at least some embodiments, the controller builds the binary file from source code present in the device software assembly. In at least some embodiments, the controller builds the binary file ready for inclusion in the final device package. In at least some embodiments, the controller converts human-readable source code into a machine-executable binary file. In at least some embodiments, the device binary package combines all binaries that need to be installed on the target hardware. In at least some embodiments, the device binary package references other packages, repackages other packages, or references a combination of both. In at least some embodiments, the device retarget binary is a specialization of the device binary. In at least some embodiments, the device retarget binary is for Software In the Loop Simulation (SILS) testing. In at least some embodiments, a functional way to integrate SILS with the device retarget binary is to use a Docker container. In at least some embodiments, the device retarget binary is repackaged and at least partially pre-configured in a Docker image. In at least some embodiments, the Docker image provides similar metadata regarding configuration, execution, and communication interfaces. In at least some embodiments, the device retarget binary requires middleware configured to integrate with the retargeted device. In at least some embodiments, the device retarget binary package provides metadata interpretable by the retargeted device, such as information regarding the configuration interface, execution of the device binary, and information regarding the configuration of the communication interface (i.e., defining IP addresses, ports, parameters, option selections, etc.).In at least some embodiments, the metadata includes information about the communication interface, such as a list of communication channels and their types, information about the execution interface, such as how to execute the binary (i.e., start / stop script, executable, etc.), etc. In at least some embodiments, the metadata enables the target hardware to receive input from and send output to the vehicle system's network (i.e., CAN bus, Ethernet, discrete, analog, etc.).

[0031] At S332, the controller, or a portion thereof, determines whether all binaries have been built. In response to all binaries not being built, the operational flow returns to building binary files at S330. In response to all binaries being built, the operational flow proceeds to generating metadata at S334. In at least some embodiments, the controller ensures that all necessary components are ready before proceeding to the next step in the packaging process.

[0032] At S334, the controller, or a portion thereof, generates metadata. In at least some embodiments, the controller generates metadata including debug information. In at least some embodiments, the controller generates the metadata in response to all binaries being successfully built and verified. In at least some embodiments, the controller generates the metadata in a metadata file. In at least some embodiments, the metadata file provides valuable information about the binaries and the build process.

[0033] At S336, the controller, or a portion thereof, creates a description of the generated device package. In at least some embodiments, the controller creates the description of the generated device package in response to successful generation of the metadata. In at least some embodiments, the controller creates a comprehensive description of the device package. In at least some embodiments, the controller creates a description that can be used to document and understand the contents of the package. In at least some embodiments, the controller creates a description that provides a human-readable overview of the package.

[0034] In at least some embodiments, the vehicle software assembly does not generate a package that includes binaries. In at least some embodiments, the vehicle software assembly packages test results and documentation.

[0035] 4 is a schematic diagram of a produced package 440 for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure. The produced package 440 includes a package description 442, metadata 444, debug information 445, operating system package binaries 447, middleware package binaries 448, application package binaries 449, build script binaries 451, and test result information 452. In at least some embodiments, the produced device package includes multiple binaries, each corresponding to one of multiple program packages included in the device software assembly and a build script included in the device software assembly. In at least some embodiments, the program package includes at least one operating system package, at least one middleware package, and at least one application package.

[0036] In at least some embodiments, generated package 440 is the output of a uniform software assembly packaging process. In at least some embodiments, generated package 440 includes components for installing and verifying software on target hardware elements. In at least some embodiments, generated package 440 is executable. In at least some embodiments, generated package 440 is configured to install software. In at least some embodiments, generated package 440 interacts with target hardware elements during the installation process. In at least some embodiments, generated package 440 is a Windows exe file or a Linux deb file.

[0037] Package description 442 is part of generated package 440. In at least some embodiments, the generated device package includes a generated device package description. In at least some embodiments, package description 442 provides an overview of the contents and functionality of generated package 440. In at least some embodiments, package description 442 is configured to clearly communicate the purpose and contents of the package to a user or other software. In at least some embodiments, package description 442 is a README file or an embedded description within package metadata. In at least some embodiments, package description 442 is a documentation package configured for integration in a domain documentation system.

[0038] Metadata 444, including debug information 445, is part of generated package 440. In at least some embodiments, metadata 444 stores additional information about generated package 440. In at least some embodiments, metadata 444 includes version numbers, dependencies, author identification, etc. In at least some embodiments, metadata 444 is configured to store various data types and structures. In at least some embodiments, metadata 444 is configured to be read by package managers and other software to understand the requirements and characteristics of the package. In at least some embodiments, metadata 444 is a JSON or XML file. In at least some embodiments, metadata 444 is embedded within the package file.

[0039] Debug information 445 is part of metadata 444. In at least some embodiments, the generated device package includes metadata that includes the debug information. In at least some embodiments, debug information 445 is configured to assist developers in identifying and fixing problems in the software included in generated package 440. In at least some embodiments, debug information 445 is configured to provide detailed error messages, stack traces, and other information useful for debugging. In at least some embodiments, debug information 445 is configured to be used by debugging tools to help developers understand and fix problems. In at least some embodiments, debug information 445 is a log file or is embedded within the package file. In at least some embodiments, debug information 445 is of a type used in software development to assist in identifying and fixing problems. In at least some embodiments, debug information 445 includes debug symbols to be resolved when attaching to a device process using a debugger, such as the GNU Project Debugger (GDB). In at least some embodiments, debug information 445 includes definitions of internal debug application programming interfaces (APIs) usable by a test framework, such as a Cockpit Software Development Kit (SDK) API, a Flutter Testing Framework server, or the like, to perform assertions or white-box testing capabilities as part of a system testing strategy. In at least some embodiments, debug information 445 includes Docker image configuration, execution, and communication interface information. In at least some embodiments, debug information 445 has very restricted access rights to prevent exposure of private information. In at least some embodiments, users of the target hardware should not have access to debug information 445.In at least some embodiments, debug information 445 is retained when deployed in production so that production issues can be debugged by developers responsible for the test framework and target hardware.

[0040] An operating system package binary 447 is part of the generated package 440. In at least some embodiments, the operating system package binary 447 comprises compiled code for an operating system package included in a device software assembly. In at least some embodiments, the operating system package binary 447 is configured to be executed by a target hardware element to install the operating system. In at least some embodiments, the operating system package binary 447 interacts with the target hardware element during the installation process. In at least some embodiments, the operating system package binary 447 is a .bin file or other executable file format. In at least some embodiments, the operating system package binary 447 is of a type used on operating system installation media.

[0041] A middleware package binary 448 is part of the generated package 440. In at least some embodiments, the middleware package binary 448 comprises compiled code for the middleware package included in the device software assembly. In at least some embodiments, the middleware package binary 448 is executed by the operating system to install the middleware. In at least some embodiments, the middleware package binary 448 interacts with the operating system during the installation process. In at least some embodiments, the middleware package binary 448 is a .bin file or other executable file format. In at least some embodiments, the middleware package binary 448 is of the type used in software installation packages.

[0042] An application package binary 449 is part of the generated package 440. In at least some embodiments, the application package binary 449 comprises compiled code for the application package included in the device software assembly. In at least some embodiments, the application package binary 449 is executed by the operating system to install the application. In at least some embodiments, the application package binary 449 interacts with the operating system during the installation process. In at least some embodiments, the application package binary 449 is a .bin file or other executable file format. In at least some embodiments, the application package binary 449 is of a type used in software installation packages.

[0043] Build script binary 451 is part of generated package 440. In at least some embodiments, build script binary 451 automates the process of compiling and building a particular software part from source code. In at least some embodiments, build script binary 451 is configured to execute a series of commands to compile and build a particular software part. In at least some embodiments, build script binary 451 is a shell script or a .bin file or other executable file format.

[0044] Test result information 452 is part of the produced package 440. In at least some embodiments, the generated device package includes the test result information. In at least some embodiments, the test result information 452 provides the results of testing the software assembly. In at least some embodiments, the test result information 452 includes pass / fail information, error messages, and other data representing test results. In at least some embodiments, the test result information 452 is obtained from a test operation of the software assembly, such as operation S220 of FIG. 2. In at least some embodiments, the test result information 452 is configured to allow a developer or other software to understand the quality of the software assembly in the generated package 440. In at least some embodiments, the test result information 452 is a text file, a JSON file, embedded within the package file, or the like. In at least some embodiments, the test results are used in software development to ensure software quality. In at least some embodiments, the test result information 452 is the same as the test result information published to a software production line or data store, along with logs and other generated test artifacts such as screen recordings, sound recordings, and core dumps.

[0045] FIG. 5 is a block diagram of a hardware configuration for packaging a uniform software assembly in accordance with at least some embodiments of the present disclosure.

[0046] An exemplary hardware configuration includes device 560 that interacts with input device 567, vehicle system 590, and ECU 592 directly or via network 569. In at least some embodiments, input device 567 is a touchscreen, microphone, camera, or any other device configured to detect input, such as tactile, auditory, or visual. In at least some embodiments, vehicle system 590 is a vehicle's computing system. In at least some embodiments, vehicle system 590 includes a controller, such as ECU 592, that communicates over a network, such as a Controller Area Network (CAN). In at least some embodiments, network 569 is an Ethernet network, or any other wired or wireless network, or a combination thereof. In at least some embodiments, device 560 is a computer or other computing device that receives input or commands from input device 567. In at least some embodiments, device 560 is integrated with input device 567. In at least some embodiments, device 560 is a computer system that executes computer-readable instructions to perform operations for packaging a uniform software assembly.

[0047] Device 560 includes a controller 562, a memory 564, an input / output interface 566, and a communication interface 568. In at least some embodiments, controller 562 includes a processor or programmable circuit that executes instructions and causes the processor or programmable circuit to perform operations in accordance with the instructions. In at least some embodiments, controller 562 includes analog or digital programmable circuitry, or any combination thereof. In at least some embodiments, controller 562 includes physically separate memory devices or circuits that interact via communications. In at least some embodiments, memory device 564 includes a non-volatile computer-readable medium capable of storing executable and non-executable data for access by controller 562 during execution of instructions. In at least some embodiments, communication interface 568 transmits and receives data from network 569. In at least some embodiments, input / output interface 566 connects to various input / output units, such as input device 567, via a parallel port, serial port, keyboard port, mouse port, monitoring port, etc., to accept commands and current information. In some embodiments, memory device 564 is external to device 560.

[0048] The control unit 562 includes a testing unit 570, an acquiring unit 572, a generating unit 574, and a building unit 576. The storage unit 564 includes a vehicle architecture specification 580, a package 582, a script 584, and building parameters 586.

[0049] Testing section 570 is circuitry or instructions in control section 562 configured to test the software assembly. In at least some embodiments, testing section 570 is configured to test the equipment software assembly according to at least one test script included in the equipment software assembly. In at least some embodiments, testing section 570 utilizes information in storage device 564, such as vehicle architecture specification 580, packages 582, and scripts 584. In at least some embodiments, testing section 570 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0050] Acquirer 572 is circuitry or instructions of controller 562 configured to acquire test result information. In at least some embodiments, acquirer 572 is configured to acquire test result information in response to testing device software assemblies according to at least one test script included in the device. In at least some embodiments, acquirer 572 records information, such as package 582, in storage device 564. In at least some embodiments, acquirer 572 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0051] Generator 574 is circuitry or instructions of controller 562 configured to generate a package from the software assemblies. In at least some embodiments, generator 574 is configured to generate an equipment package from the equipment software assemblies, the generated equipment package being executable to install and verify software on target hardware elements of a vehicle architecture specification included in the equipment software assembly. In at least some embodiments, generator 574 utilizes information in storage 564, such as vehicle architecture specification 580, packages 582, scripts 584, and build parameters 586. In at least some embodiments, generator 574 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0052] Builder 576 is circuitry or instructions in controller 562 configured to build a binary. In at least some embodiments, builder 576 is configured to build multiple binaries. In at least some embodiments, builder 576 utilizes information in storage 564, such as packages 582 and scripts 584. In at least some embodiments, builder 576 includes subsections for performing additional functions, as described in the preceding flowcharts. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0053] In at least some embodiments, the apparatus is another device capable of processing logical functions to perform the operations herein. In at least some embodiments, the controller and memory need not be entirely separate devices, and in some embodiments share circuitry or one or more computer-readable media. In at least some embodiments, the memory includes a hard drive that stores both computer-executable instructions and data accessed by the controller, and the controller includes a combination of a central processing unit and RAM, where the computer-executable instructions can be copied in whole or in part for execution by the CPU during performance of the operations herein.

[0054] In at least some embodiments where the device is a computer, programs installed on the computer can cause the computer to function as or perform operations associated with the devices of the embodiments described herein, and in at least some embodiments, such programs are executable by a processor to cause the computer to perform specific operations associated with some or all of the blocks in the flowcharts and block diagrams described herein.

[0055] At least some embodiments are described with reference to flowcharts and block diagrams, whose blocks represent (1) steps in a process in which an operation is performed, or (2) sections of a controller responsible for performing an operation. In at least some embodiments, particular steps and sections are implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable medium, and / or a processor provided with computer-readable instructions stored on a computer-readable medium. In at least some embodiments, the dedicated circuitry includes digital and / or analog hardware circuitry, including integrated circuits (ICs) and / or discrete circuits. In at least some embodiments, the programmable circuitry includes reconfigurable hardware circuitry including logical AND, OR, XOR, NAND, NOR, and other logic operations, flip-flops, registers, memory elements, etc., such as, for example, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), etc.

[0056] In at least some embodiments, a computer-readable storage medium comprises a tangible device capable of holding and storing instructions for use by an instruction execution device. In some embodiments, a computer-readable storage medium includes, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list 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), portable compact disc (CD-ROM) read-only memory, digital versatile disc (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or structures in grooves having instructions recorded thereon, and any suitable combination of the above. As used herein, computer-readable media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over a wire.

[0057] In at least some embodiments, the computer-readable program instructions described herein are downloadable to each computing / processing device from a computer-readable storage medium or to an external computer or external storage device over a network, e.g., the Internet, a local area network, a wide area network, and / or a wireless network. In at least some embodiments, the network includes copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. In at least some embodiments, a network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0058] In at least some embodiments, the computer-readable program instructions for performing the operations described above are assembler instructions, instruction set architecture instructions (ISA), machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, e.g., object-oriented programming languages ​​such as Smalltalk®, C++®, and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages. In at least some embodiments, the computer-readable program instructions execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In at least some embodiments, in the latter scenario, the remote computer is connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection is to an external computer (e.g., via the Internet using an Internet Service Provider). In at least some embodiments, electronic circuitry, including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), executes computer-readable program instructions by individualizing the electronic circuitry and utilizing state information of the computer-readable program instructions to carry out aspects of the present invention.

[0059] Although the embodiments of the present invention have been described above, the technical scope set forth in the claims is not limited to the above embodiments. Those skilled in the art will understand that various modifications and improvements to the above-described embodiments are possible. Furthermore, those skilled in the art will understand from the claims that forms incorporating such modifications or improvements are also included within the technical scope of the present invention.

[0060] The operations, procedures, steps, and stages of each process performed by the apparatus, system, program, and method shown in the claims, embodiments, or drawings can be performed in any order, unless the order is indicated by "prior," "before," etc., and unless output from a previous process is used in a later process. Note that even if a process flow is described in the claims, embodiments, or drawings using terms such as "first" or "next," the description does not necessarily mean that the processes must be performed in the order described.

[0061] In at least some embodiments, packaging the uniform software assembly is performed by testing the device software assembly according to at least one test script included in the device software assembly to obtain test result information; and generating a device package from the device software assembly, the generated device package being executable to install and verify software on target hardware elements of a vehicle architecture specification included in the device software assembly. The generated device package includes a plurality of binaries, each binary corresponding to a program package among a plurality of program packages included in the device software assembly and a build script included in the device software assembly, metadata including debug information, a description of the generated device package, and test result information. In at least some embodiments, the at least one test script is configured to interact with a vehicle simulation. In at least some embodiments, the target hardware element is an ECU of the vehicle architecture specification. In at least some embodiments, the device software assembly further includes a model configured to emulate an adjacent ECU. In at least some embodiments, generating includes building a plurality of binaries. In at least some embodiments, the device software assembly further includes a model configured to generate binary code. In at least some embodiments, packaging the uniform software assembly further includes testing the vehicle software assembly according to at least one vehicle test script included in the vehicle software assembly to generate vehicle test result information. In at least some embodiments, packaging the uniform software assembly further includes generating a vehicle package from the vehicle software assembly, the vehicle package being executable to install and verify the software on each hardware element, including the target hardware elements of the vehicle architecture specification.In at least some embodiments, the plurality of program packages includes at least one operating system package, at least one middleware package, and at least one application package. In at least some embodiments, the vehicle architecture specification includes a CAN (Controller Area Network) communication specification. In at least some embodiments, the vehicle architecture specification includes a LAN (Local Area Network) communication specification. In at least some embodiments, the vehicle architecture specification includes an acceptable version of the at least one operating system package.

[0062] In at least some embodiments, packaging the uniform software assembly is performed by a processor that executes instructions in accordance with the aforementioned operations, or by an apparatus that includes a controller that includes circuitry configured to perform the aforementioned operations.

[0063] The foregoing summary sets forth features of some embodiments so that those skilled in the art may better understand aspects of the present disclosure. Those skilled in the art should appreciate that this disclosure may readily be used as a basis for designing or modifying other processes and structures for carrying out the same purposes and / or achieving the same advantages of the embodiments presented herein. Those skilled in the art should also appreciate that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the present disclosure.

Claims

1. testing the device software assembly according to at least one test script included in the device software assembly to obtain test result information; generating an equipment package from the equipment software assembly, the generated equipment package being executable to install and verify software on target hardware elements of a vehicle architecture specification included in the equipment software assembly; [0023] In response to execution by one or more processors, instructions cause the execution of operations including: The generated device package comprises: a plurality of binaries, each binary corresponding to a program package among a plurality of program packages included in the device software assembly and a build script included in the device software assembly; Metadata containing debug information; a description of the generated device package; The test result information; a computer program comprising:

2. The computer program product of claim 1 , wherein the at least one test script is configured to interact with a vehicle simulation.

3. The computer program product of claim 1 , wherein the target hardware element is an ECU of the vehicle architecture specification.

4. The computer program product of claim 3 , wherein the device software assembly further comprises a model configured to emulate an adjacent ECU.

5. The computer program product of claim 1 , wherein the generating comprises building the plurality of binaries.

6. The computer program product of claim 5 , wherein the device software assembly further comprises a model configured to generate binary code.

7. 10. The computer program product of claim 1, wherein the operations further comprise testing the vehicle software assembly according to at least one vehicle test script included in the vehicle software assembly to generate vehicle test result information.

8. 8. The computer program product of claim 7, wherein the operations further include generating a vehicle package from the vehicle software assembly, the vehicle package executable to install and verify software on each hardware element, including the target hardware element, of the vehicle architecture specification.

9. The computer program product of claim 1 , wherein the plurality of program packages includes at least one operating system package, at least one middleware package, and at least one application package.

10. The computer program product of claim 1 , wherein the vehicle architecture specification includes a Controller Area Network (CAN) communication specification.

11. The computer program product of claim 1 , wherein the vehicle architecture specification includes a Local Area Network (LAN) communication specification.

12. 12. A computer program product according to any one of claims 1 to 11, wherein the vehicle architecture specification includes acceptable versions of at least one operating system package.

13. testing the device software assembly according to at least one test script included in the device software assembly to obtain test result information; generating an equipment package from the equipment software assembly, the generated equipment package being executable to install and verify software on target hardware elements of a vehicle architecture specification included in the equipment software assembly; The processor executes The generated device package comprises: a plurality of binaries, each binary corresponding to a program package among a plurality of program packages included in the device software assembly and a build script included in the device software assembly; Metadata containing debug information; a description of the generated device package; The test result information; A method comprising:

14. The method of claim 13 , wherein the at least one test script is configured to interact with a vehicle simulation.

15. The method of claim 13 , wherein the target hardware element is an ECU of the vehicle architecture specification.

16. The method of claim 15 , wherein the device software assembly further includes a model configured to emulate an adjacent ECU.

17. The method of claim 13 , wherein the generating includes the processor building the plurality of binaries.

18. The method of claim 17 , wherein the device software assembly further comprises a model configured to generate binary code.

19. 19. The method of any one of claims 13 to 18, further comprising the processor testing the vehicle software assembly according to at least one vehicle test script included in the vehicle software assembly to generate vehicle test result information.

20. testing the device software assembly according to at least one test script included in the device software assembly to obtain test result information; generating an equipment package from the equipment software assembly, the generated equipment package being executable to install and verify software on target hardware elements of a vehicle architecture specification included in the equipment software assembly; a controller including circuitry configured to perform operations including The generated device package comprises: a plurality of binaries, each binary corresponding to a program package among a plurality of program packages included in the device software assembly and a build script included in the device software assembly; Metadata containing debug information; a description of the generated device package; The test result information; 1. An apparatus comprising:

Images