Software development by testing and releasing incremental software components

Individual testing and release of software components based on automated monitoring and notification of failures addresses inefficiencies in rebuilding and testing, improving efficiency and reducing manual effort.

JP7794340B2Active Publication Date: 2026-01-06TOYOTA JIDOSHA KK
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2025004600
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2024-05-15
Filing Date
2025-01-14
Publication Date
2026-01-06
Estimated Expiration
2045-01-14

AI Technical Summary

Technical Problem

In software systems, updating a component requires rebuilding the entire system and manual testing, which is inefficient and time-consuming, especially when some components may function properly while others fail tests.

Method used

Individual testing of each software component, including those that depend on an updated component, followed by releasing only those that pass tests, with automated monitoring and notification of failures.

Benefits of technology

Reduces time and resources needed for rebuilding and analysis by identifying issues early in the build process and directing developers to specific components, enhancing efficiency and reducing manual review.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007794340000001
    Figure 0007794340000001
  • Figure 0007794340000002
    Figure 0007794340000002
  • Figure 0007794340000003
    Figure 0007794340000003
Patent Text Reader

Abstract

To provide software development.SOLUTION: Software development is executed by: detecting the update of a hardware communication specification and constructing a new version of an upstream-side software component in a software system on the basis of the updated hardware communication specification; testing the new version of the upstream-side software component; in response to the success of the test for the new version of the upstream-side software component, releasing the new version of the upstream-side software component into the software system; constructing a new version of a downstream-side software component on the basis of the new version of the upstream-side software component; testing the new version of the downstream-side software component; and in response to the success of the test for the new version of the downstream-side software component, releasing the new version of the downstream-side software component into the software system.SELECTED DRAWING: Figure 1
Need to check novelty before this filing date? Find Prior Art

Description

[Background technology]

[0001] A software system, such as a software system for a vehicle, contains multiple software components, some of which depend on other software components as part of the build process. Updating a software component of a software system requires rebuilding the software system. The rebuilt software system is tested to verify functionality. If the software system passes the tests, the software system is released as a new version. If the software system does not pass the tests, the software system is not released. 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 system development for software development by incremental software component testing and release, according to at least some embodiments of the present disclosure. [Figure 2] FIG. 2 is an operational flow for software development with incremental software component testing and release, according to at least some embodiments of the present disclosure. [Figure 3] FIG. 3 is an operational flow for building a new version of a software component according to at least some embodiments of the present disclosure. [Figure 4]FIG. 4 is a block diagram of a hardware configuration for software development with incremental software component testing and release, according to 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 also contemplated. In addition, the disclosure may repeat reference numerals and / or letters in the 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] In software systems known to the inventors, rebuilding the software system includes rebuilding software components that directly or indirectly depend on the initially updated software component. In such software systems, one or more of the rebuilt software components in the software system may actually be functioning properly. A developer manually reviews each software component to determine the cause of a test failure, and repeatedly tests the software system until the software system passes the test.

[0006] In at least some embodiments of the present disclosure, each software component of the initially updated software component and any software components that depend on the initially updated software component are individually tested, either directly or indirectly, to verify local functionality. In at least some embodiments, software components that pass the tests are released as updated software components, and developers are notified of software components that do not pass the tests.

[0007] In at least some embodiments, by testing software components individually, problems are known early in the build process, reducing time and resources required to build dependent software components, and developers are directed to problems with specific software components, reducing analysis time.

[0008] For example, consider a rain response application, where the application detects weather via sensors and, if the detected weather includes rain, closes the vehicle windows to protect the interior of the vehicle from water damage. In this example, the vehicle system is divided into four software components: weather, central, window, and I / O. In this example, the rain response application causes these subsystems to communicate with each other. In at least some embodiments, one such communication is weather data from the weather subsystem to the central subsystem. In at least some embodiments, if the abstraction layer does not currently define a signal or data type related to weather data, the hardware communication specification is updated to include a new signal or data type for "weather data." In at least some embodiments, the update of the hardware communication specification triggers testing and updating of the abstraction layer, which in turn triggers testing and updating of all layers through the system layer.

[0009] 1 is a schematic diagram of a software system development for incremental software component testing and release software development in accordance with at least some embodiments of the present disclosure, including an upstream software component 110, downstream software components 112, 113, and 114, and a software system 116.

[0010] Upstream software component 110 is first updated according to an updated hardware communication specification. In at least some embodiments, the hardware communication specification includes a list of signals and data types usable by the software system. In at least some embodiments, the hardware communication specification is for a vehicle's Controller Area Network (CAN). In at least some embodiments, upstream software component 110 is configured to provide functionality to downstream software components 112, 113, and 114. In at least some embodiments, upstream software component 110 is configured to handle tasks such as data processing and user interface management. In at least some embodiments, upstream software component 110 is configured to interact with external APIs, databases, or other software systems other than software system 116. In at least some embodiments, upstream software component 110 is a device driver, a library, or a service within a microservices architecture.

[0011] Downstream software components 112, 113, and 114 are updated in response to successful updates of upstream software component 110, and each includes specific functionality related to processing data or functions received from the upstream software component. In at least some embodiments, downstream software components 112, 113, and 114 are configured to depend on upstream software component 110. In at least some embodiments, downstream software components 112, 113, and 114 are updated based on changes to upstream software component 110. In at least some embodiments, downstream software components 112, 113, and 114 are configured to be tested and released as new versions in response to passing the tests. In at least some embodiments, downstream software components 112, 113, and 114 can interact with each other based on the design of the software system. In at least some embodiments, downstream software components 112, 113, and 114 are configured to handle various tasks depending on their role in the software system, such as weather detection, window operation, or control interaction for a vehicle. In at least some embodiments, the downstream software components 112, 113, 114 are configured to interact with other software components in the system or with external components such as databases, APIs, or hardware devices. In at least some embodiments, the downstream software components 112, 113, 114 are modules in a monolithic application, services in a microservices architecture, or libraries used by other parts of the system.

[0012] The software system 116 is constructed from all the software components (110, 112, 113, 114) and provides the overall functionality of the application. In at least some embodiments, the software system 116 is the entire system including all the software components. In at least some embodiments, the software system 116 is configured to interact with and coordinate the operation of all the software components 110, 112, 113, 114. In at least some embodiments, the software system 116 is configured to provide a wide range of functionality depending on the application, from data processing and storage to user interface rendering and business logic implementation. In at least some embodiments, the software system 116 is configured for vehicle operation. In at least some embodiments, the software system 116 includes applications that allow end users to interact with or provide services to other systems.

[0013] 2 is an operational flow for software development by incremental testing and release of software components in accordance with at least some embodiments of the present disclosure. In at least some embodiments, the operational flow provides a method for software development by incremental testing and release of software components in accordance with at least some embodiments of the subject disclosure. In at least some embodiments, the method is performed by a server controller, such as controller 402 of server 400 in FIG. 4 described below.

[0014] At S220, the controller, or a portion thereof, detects an update to the hardware communication specification. In at least some embodiments, the controller monitors changes or updates to the hardware communication specification. In at least some embodiments, the controller detects updates to the hardware communication specification. In at least some embodiments, the controller monitors through an automated system that tracks changes to a specification or database. In at least some embodiments, the controller causes software components that interact (communicate) with the hardware to be updated in response to detecting the updated hardware communication specification. In at least some embodiments, the controller initiates a series of actions in the software development process. In at least some embodiments, the controller continuously monitors the hardware communication specification.

[0015] In S223, the control unit, or a portion thereof, builds a new version of the software component. In at least some embodiments, the control unit builds a new version of the affected software component based on the detected update to the hardware communication specification. In at least some embodiments, the control unit compiles code to create an executable package of the software component. In at least some embodiments, the control unit creates a new version of the software component that is compatible with the updated hardware communication specification. In at least some embodiments, the control unit executes the operational flow of FIG. 3 , described below. In at least some embodiments, the control unit determines that multiple downstream software components depend on the upstream software component, or that one of the multiple downstream software components depends on the upstream software component.

[0016] At S226, the controller, or a portion thereof, builds the software system. In at least some embodiments, the controller integrates the newly built software components into the software system. In at least some embodiments, the controller tests the software system to verify overall functionality. In at least some embodiments, the controller utilizes a system builder or an automated build system to integrate the software components. In at least some embodiments, the controller releases a new version of the software system.

[0017] 3 is an operational flow for building a new version of a software component, in accordance with at least some embodiments of the present disclosure. In at least some embodiments, the operational flow provides a method for building a new version of a software component, in accordance with at least some embodiments of the present disclosure. In at least some embodiments, the method is performed by a controller of a server, such as controller 402 of server 400 in FIG. 4, described below.

[0018] At S330, the control unit, or a portion thereof, builds a new version of the software component. In at least some embodiments, the control unit builds a new version of the upstream software component within the software system based on an updated hardware communication specification. In at least some embodiments, the control unit creates a new version of the software component based on an updated specification or dependency. In at least some embodiments, the control unit builds a new version of the downstream software component based on the new version of the upstream software component. In at least some embodiments, the control unit determines that the downstream software component depends on the upstream software component before building the new version of the downstream software component. In at least some embodiments, the control unit rebuilds the downstream software component in response to receiving modified code for the downstream software component. In at least some embodiments, building a new version of the downstream software component includes building a new version of each of the plurality of downstream software components. In at least some embodiments, the control unit further builds a new version of a further downstream software component based on the new version of the downstream software component in response to successful testing of the new version of the downstream software component. In at least some embodiments, the control unit builds a new version of the software system based on each new version of the plurality of downstream software components in response to successful testing of each new version of the plurality of downstream software components.

[0019] At S332, the controller, or a portion thereof, tests the new version of the software component. In at least some embodiments, the controller tests the new version of the upstream software component. In at least some embodiments, the controller performs various tests on the newly built software component to verify its functionality and compatibility. In at least some embodiments, testing the new version of the upstream software component includes determining one or more functional requirements of the upstream software component. In at least some embodiments, testing the new version of the upstream software component includes testing functionality specific to the upstream software component. In at least some embodiments, the controller utilizes a simulator to perform the testing. In at least some embodiments, testing the new version of the upstream software component includes simulating a hardware component. In at least some embodiments, testing the new version of the downstream software component includes testing each new version of the plurality of downstream software components. In at least some embodiments, the controller tests the new version of the additional downstream software component. In at least some embodiments, the controller uses a set of pre-written tests to perform testing of the simulated system. In at least some embodiments, each of the pre-written tests is designed to test a unique aspect of a package at any or all layers of the software system.

[0020] In S333, the controller, or a portion thereof, determines whether the new version of the software component passed the tests. In response to the new version of the software component not passing the tests, the operational flow proceeds to indicate that the tests were not successful, in S335. In response to the new version of the software component not passing the tests, the operational flow proceeds to determine whether a revised package has been received, in S336. In at least some embodiments, the controller evaluates the results of the testing process. In at least some embodiments, the controller compares the output of the new version of the software component with an expected output. In at least some embodiments, the new version of the software component passes the tests only if all tests yield the correct output.

[0021] At S335, the controller, or a portion thereof, indicates that the test was unsuccessful. In at least some embodiments, the controller, in response to the unsuccessful testing of the new version of the downstream software component, indicates that the test of the downstream software component was unsuccessful. In at least some embodiments, the controller notifies interested parties about the unsuccessful test results. In at least some embodiments, the controller sends a notification to the developer. In at least some embodiments, the controller includes the name and version of the software component in the notification. In at least some embodiments, the controller, in response to the unsuccessful testing of the new version of the downstream software component, maintains the new version of the upstream software component.

[0022] At S336, the controller, or a portion thereof, determines whether modified code has been received. In response to receiving modified code, the operational flow returns to building a new version of the software component at S330. In response to not receiving modified code, the operational flow returns to determining whether a modified package has been received at S336. In at least some embodiments, the controller repeatedly checks whether modified code for the software component has been received.

[0023] At S338, the control unit, or a portion thereof, releases the new version of the software component. In at least some embodiments, the control unit releases the new version of the software component to a software component repository. In at least some embodiments, this action does not cause any external action. In at least some embodiments, the control unit makes the updated software component available for further updates to the software system. In at least some embodiments, in response to successful testing of the new version of the upstream software component, the control unit releases the new version of the upstream software component into the software system, builds a new version of the downstream software component based on the new version of the upstream software component, tests the new version of the downstream software component, and, in response to successful testing of the new version of the downstream software component, releases the new version of the downstream software component into the software system.

[0024] In S339, the control unit, or a portion thereof, determines whether there are any remaining dependent software components. In response to remaining dependent software components, the operational flow returns to building a new version of the software component in S330. In response to no remaining dependent software components, the operational flow ends. In at least some embodiments, the control unit checks whether there are any remaining software components that depend on the newly released software component. In at least some embodiments, the control unit references a predetermined sequence of software components to build.

[0025] In at least some embodiments, building and testing of new versions of downstream software components is performed in parallel with building and testing of other new versions of each other of the multiple downstream software components.

[0026] FIG. 4 is a block diagram of a hardware configuration for software development with incremental software component testing and release, according to at least some embodiments of the present disclosure.

[0027] An exemplary hardware configuration includes a server 400 that interacts with an input device 407 directly or via a network 409. In at least some embodiments, the input device 407 is a touchscreen, a microphone, a camera, or any other device configured to detect tactile, auditory, visual, or other input. In at least some embodiments, the network 409 is an Ethernet network, a controller area network (CAN), or any other wired or wireless network, or a combination thereof. In at least some embodiments, the server 400 is a computer or other computing device that receives input or commands from the input device 407. In at least some embodiments, the server 400 is integrated with the input device 407. In at least some embodiments, the server 400 is a computer system that executes computer-readable instructions to perform operations for software development through testing and releasing incremental software components.

[0028] Server 400 includes a controller 402, storage 404, input / output (I / O) interface 406, and a communication interface 408. In at least some embodiments, controller 402 includes a processor or programmable circuit that executes instructions, causing the processor or programmable circuit to perform operations in accordance with the instructions. In at least some embodiments, controller 402 includes analog or digital programmable circuitry, or any combination thereof. In at least some embodiments, controller 402 includes physically separate storage devices or circuits that interact via communications. In at least some embodiments, storage 404 includes a non-volatile computer-readable medium capable of storing executable and non-executable data for access by controller 402 during execution of instructions. In at least some embodiments, communication interface 408 transmits and receives data from network 409. In at least some embodiments, I / O interface 406 connects to various inputs and outputs, such as input device 407, via a parallel port, serial port, keyboard port, mouse port, monitoring port, etc., to accept commands and current information. In some embodiments, storage 404 is external to server 400.

[0029] The control device 402 includes a detection unit 440, a construction unit 442, a testing unit 444, and a release unit 446. The storage device 404 includes a hardware communication specification 450, a software component package 452, functional requirements 454, and simulation parameters 456.

[0030] Detector 440 is circuitry or instructions in controller 402 configured to detect updates to the hardware communication specification. In at least some embodiments, detector 440 is configured to detect updates to the hardware communication specification. In at least some embodiments, detector 440 utilizes information in storage 404, such as hardware communication specification 450. In at least some embodiments, detector 440 includes subsections (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.

[0031] Builder 442 is circuitry or instructions in controller 402 configured to build new versions of software components. In at least some embodiments, builder 442 is configured to build new versions of upstream software components in the software system based on updated hardware communication specifications. In at least some embodiments, builder 442 records information in storage 404, such as software component package 452. In at least some embodiments, builder 442 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.

[0032] Testing unit 444 is circuitry or instructions in control unit 402 configured to test new versions of software components. In at least some embodiments, testing unit 444 is configured to test new versions of upstream software components. In at least some embodiments, testing unit 444 utilizes information in storage 404, such as functional requirements 454 and simulation parameters 456. In at least some embodiments, testing unit 444 includes subsections (subunits) 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.

[0033] The release unit 446 is circuitry or instructions in the control unit 402 configured to release new versions of software components. In at least some embodiments, the release unit 446 is configured to release new versions of upstream software components in the software system. In at least some embodiments, the release unit 446 utilizes information in the storage unit 404, such as software component packages 452. In at least some embodiments, the release unit 446 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.

[0034] In at least some embodiments, the device is a separate device capable of processing logical functions to perform the operations herein. In at least some embodiments, the controller and storage device 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 storage unit 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.

[0035] 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.

[0036] 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, dedicated circuitry includes digital and / or analog hardware circuitry, including integrated circuits (ICs) and / or discrete circuits. In at least some embodiments, programmable circuitry includes reconfigurable hardware circuitry, such as logical AND, OR, XOR, NAND, NOR, and other logic operations, flip-flops, registers, memory elements, including, for example, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), etc.

[0037] 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, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, 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), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), 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.

[0038] 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 within 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 within the respective computing / processing device.

[0039] In at least some embodiments, the computer-readable program instructions for performing the operations described above are assembler instructions, instruction set architecture instructions, 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, partially as a standalone software package, partially on the user's computer, partially on a remote computer, or partially 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, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), executes computer-readable program instructions by utilizing state information of the computer-readable program instructions to individualize the electronic circuitry to perform aspects of the present invention.

[0040] 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.

[0041] 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.

[0042] In at least some embodiments, software development through incremental software component testing and release is performed by detecting updates to a hardware communication specification, building a new version of an upstream software component in the software system based on the updated hardware communication specification, testing the new version of the upstream software component, and releasing the new version of the upstream software component in the software system in response to successful testing of the new version of the upstream software component, building a new version of a downstream software component based on the new version of the upstream software component, testing the new version of the downstream software component, and releasing the new version of the downstream software component in the software system in response to successful testing of the new version of the downstream software component.

[0043] In at least some embodiments, software development through incremental software components further includes indicating unsuccessful testing of the downstream software component in response to unsuccessful testing of the new version of the downstream software component. In at least some embodiments, software development through incremental software component testing and release further includes maintaining a new version of the upstream software component in response to unsuccessful testing of the new version of the downstream software component. In at least some embodiments, software development through incremental software component testing and release further includes rebuilding the downstream software component in response to receiving a modified package of the downstream software component. In at least some embodiments, testing the new version of the upstream software component includes testing functionality specific to the upstream software component. In at least some embodiments, testing the new version of the upstream software component includes determining one or more functional requirements of the upstream software component. In at least some embodiments, testing the new version of the upstream software component includes simulating a hardware component. In at least some embodiments, the hardware communication specification includes a list of signals and data types usable by the software system. In at least some embodiments, the hardware communication specification is for a controller area network (CAN) of the vehicle. In at least some embodiments, software development by incremental software component testing and release further includes determining that a downstream software component depends on an upstream software component before building a new version of the downstream software component.In at least some embodiments, software development by incremental testing and releasing software components further includes determining that a plurality of downstream software components depend on the upstream software component or that a downstream software component among the plurality of downstream software components depends on the upstream software component. In at least some embodiments, software development by incremental testing and releasing software components further includes determining that a plurality of downstream software components depend on the upstream software component. In at least some embodiments, software development by incremental testing and releasing software components further includes determining that a plurality of downstream software components depend on the upstream software component. In at least some embodiments, building a new version of the downstream software component includes building a new version of each of the plurality of downstream software components, and testing the new version of the downstream software component includes testing each of the plurality of downstream software components. In at least some embodiments, building and testing the new version of the downstream software component is performed in parallel with building and testing the new versions of each of the plurality of downstream software components. In at least some embodiments, software development by incremental testing and releasing software components further includes, in response to successful testing of the new version of the downstream software component, building a new version of a further downstream software component based on the new version of the downstream software component and testing the new version of the further downstream software component. In at least some embodiments, software development through incremental software component testing and release further includes building a new version of the software system based on each new version of the plurality of downstream software components in response to successful testing of each new version of the plurality of downstream software components.

[0044] In at least some embodiments, software development through incremental software component testing and release is performed by an apparatus that includes a processor that executes instructions in accordance with the operations described above, or a controller that includes circuitry configured to perform the operations described above.

[0045] 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. Detecting updates to hardware communication specifications; building a new version of an upstream software component within the software system based on the updated hardware communication specification; testing the new version of the upstream software component; in response to the testing of the new version of the upstream software component being successful; Releasing the new version of the upstream software component into the software system; building a new version of the downstream software component based on the new version of the upstream software component; testing the new version of the downstream software component; in response to the testing of the new version of the downstream software component being successful; Releasing the new version of the downstream software component into the software system; 1. A computer program having instructions that, in response to execution by one or more processors, cause the performance of operations including:

2. 2. The computer program product of claim 1, wherein the operations further comprise: indicating, in response to the test of the new version of the downstream software component being unsuccessful, that the test of the downstream software component was unsuccessful.

3. 3. The computer program product of claim 2, wherein the operations further comprise, in response to the testing of the new version of the downstream software component being unsuccessful, maintaining the new version of the upstream software component.

4. The computer program product of claim 2 , wherein the operations further comprise rebuilding the downstream software component in response to receiving a modified package of the downstream software component.

5. The computer program product of claim 1 , wherein the testing of the new version of the upstream software component includes testing functionality specific to the upstream software component.

6. 6. The computer program product of claim 5, wherein the testing of the new version of the upstream software component includes determining one or more functional requirements of the upstream software component.

7. The computer program product of claim 5 , wherein the testing of the new version of the upstream software component includes simulating a hardware component.

8. The computer program product of claim 1 , wherein the hardware communication specification includes a list of signals and data types usable by the software system.

9. 9. The computer program product of claim 8, wherein the hardware communication specification is for a vehicle controller area network (CAN).

10. 10. The computer program product of claim 1, wherein the operations further include determining that the downstream software component depends on the upstream software component before building the new version of the downstream software component, building the new version of the downstream software component based on the new version of the upstream software component, testing the new version of the upstream software component, and determining that the downstream software component depends on the upstream software component if the test of the new version of the upstream software component is successful.

11. 11. The computer program product of claim 10, wherein the operations further include determining that a plurality of the downstream software components depend on the upstream software component or that one of the downstream software components depends on the upstream software component; building the new versions of the downstream software components based on the new versions of the upstream software component, testing the new versions of the downstream software components, and determining that the downstream software components depend on the upstream software component if the testing of the new versions of the downstream software components is successful; building the new version of the one of the downstream software components based on the new version of the upstream software component, testing the new version of the one of the downstream software components, and determining that the one of the downstream software components depends on the upstream software component if the testing of the new version of the one of the downstream software components is successful.

12. building the new version of the downstream software component includes building a new version of each of a plurality of the downstream software components; The computer program product of claim 11 , wherein the testing the new version of the downstream software component comprises testing the new version of each of a plurality of the downstream software components.

13. The computer program product of claim 12 , wherein the building and testing of the new version of the downstream software component is performed in parallel with the building and testing of the new versions of each of the plurality of downstream software components.

14. The operation is further responsive to the testing of the new version of the downstream software component being successful, building a new version of a further downstream software component based on the new version of the downstream software component; The computer program product of claim 12 , further comprising testing the new version of the further downstream software component.

15. 13. The computer program product of claim 12, wherein the operations further include, in response to the testing of the new version of each of the plurality of downstream software components being successful, building a new version of the software system based on the new version of each of the plurality of downstream software components.

16. Detecting updates to hardware communication specifications; building a new version of an upstream software component within the software system based on the updated hardware communication specification; testing the new version of the upstream software component; in response to the testing of the new version of the upstream software component being successful; Releasing the new version of the upstream software component into the software system; building a new version of the downstream software component based on the new version of the upstream software component; testing the new version of the downstream software component; in response to the testing of the new version of the downstream software component being successful; Releasing the new version of the downstream software component into the software system; How the processor performs the

17. 17. The method of claim 16, further comprising: in response to the testing of the new version of the downstream software component being unsuccessful, the processor indicating that the testing of the downstream software component was unsuccessful.

18. 18. The method of claim 17, further comprising, in response to the testing of the new version of the downstream software component being unsuccessful, the processor retaining the new version of the upstream software component.

19. 19. The method of claim 17 or 18, further comprising the processor, in response to receiving a modified package of the downstream software component, rebuilding the downstream software component.

20. Detecting updates to hardware communication specifications; building a new version of an upstream software component within the software system based on the updated hardware communication specification; testing the new version of the upstream software component; in response to the testing of the new version of the upstream software component being successful; Releasing the new version of the upstream software component into the software system; building a new version of the downstream software component based on the new version of the upstream software component; testing the new version of the downstream software component; in response to the testing of the new version of the downstream software component being successful; Releasing the new version of the downstream software component into the software system; 10. An apparatus having a controller including circuitry configured to perform operations including:

Citation Information

Patent Citations

  • Program management system and program management method

    JP2002251285A

  • Operation attribute specifying device for electronic application system and program, operation attribute specifying method, and computer system

    JP2004046530A

  • Testing tools including automated multi-dimensional traceability matrices for implementing and validating complex software systems

    JP2007535723A

  • Changelog Transformation and Correlation in a Multi-Tenant Cloud Service

    US20170034010A1

  • Component firmware updates

    US20220091838A1