Embedded software development with continuous integration using a pipeline agent

Abstract

A method for performing integrated software development on a software product comprising multiple independent software components, comprising using one or more processors to: receive an instruction to make changes to a first software component among the multiple independent software products; in response to the instruction, automatically update an architecture definition associated with the first software component based on the changes made to the first software component; update the architecture of the software product based on the changes made to the first software component; compile the software product; and release build artifacts associated with the software product.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 743,011, filed January 8, 2025. The entire disclosure of the above-cited application is incorporated herein by reference. Technical Field

[0003] This disclosure relates to software architectures used for developing and integrating software applications. Background Technology

[0004] Vehicles (such as cars, trucks, SUVs, crossovers, minivans, boats, aircraft, all-terrain vehicles, recreational vehicles, or other suitable forms of transportation) typically include steering systems, such as electronic power steering (EPS), steer-by-wire (SbW), hydraulic steering, or other suitable steering systems. These steering systems generally control various aspects of the vehicle's steering, including providing steering assistance to the operator and controlling the steering wheels. Steering systems and other automotive systems require the development, integration, and implementation of various software components and applications. Summary of the Invention

[0005] This disclosure generally relates to integrated software development processes.

[0006] A method for performing integrated software development on a software product comprising multiple independent software components, comprising using one or more processors to: receive an instruction to make changes to a first software component among the multiple independent software products; in response to the instruction, automatically update an architecture definition associated with the first software component based on the changes made to the first software component; update the architecture of the software product based on the changes made to the first software component; compile the software product; and release a build artifact associated with the software product.

[0007] Other aspects include systems, computing devices, one or more processors, etc., configured to perform functions associated with the methods described herein. Attached Figure Description

[0008] This disclosure can be best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be emphasized that, by convention, the various features in the drawings are not drawn to scale. Instead, for clarity, the dimensions of the various features have been arbitrarily enlarged or reduced.

[0009] Figure 1A A vehicle based on the principles of the present invention is shown in general.

[0010] Figure 1B The controller according to the principles of the present invention is shown in general.

[0011] Figure 1C It roughly illustrates the embedded software development process.

[0012] Figure 2 An exemplary embedded software development process for implementing continuous integration pipelines and related technologies in accordance with the principles of this disclosure is generally illustrated.

[0013] Figure 3 An exemplary pipeline process for modifying independent software components, based on the principles of this disclosure, is generally illustrated.

[0014] Figure 4A and Figure 4B An exemplary pipeline process for architectural changes, based on the principles of this disclosure, is generally illustrated.

[0015] Figure 5 An exemplary computing device configured to implement various aspects of a pipeline process, based on the principles of this disclosure, is generally illustrated. Detailed Implementation

[0016] The following discussion pertains to various embodiments of this disclosure. While one or more of these embodiments may be preferred, the disclosed embodiments should not be construed as or otherwise used to limit the scope of this disclosure, including the claims. Furthermore, those skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is merely illustrative of that embodiment and does not imply that the scope of this disclosure, including the claims, is limited to that embodiment.

[0017] The systems and methods disclosed herein are configured to facilitate embedded software development (e.g., the development of software products, documentation, infrastructure, etc., comprising multiple independent software components) by implementing continuous integration pipeline technology. For example, a series of scripts are implemented to leverage the capabilities of continuous integration pipelines (Microsoft Azure Pipelines, GitLab, Jenkins, etc.) to automate portions of the software development process. Multiple different processes or procedures are automated based on actions from one or more users. A pipeline agent is used to execute the different processes; this pipeline agent is configured to perform various integration steps and publish / output the integration results.

[0018] Figure 1AA vehicle 10 according to the principles of the present invention is generally illustrated. Vehicle 10 may include any suitable vehicle (e.g., a car, truck, SUV, minivan, crossover, any other passenger vehicle, any suitable commercial vehicle, or any other suitable vehicle). Although vehicle 10 is shown as a wheeled passenger vehicle used on a road, the principles of this disclosure can be applied to other vehicles (e.g., airplanes, ships, trains, drones, or other suitable vehicles). Vehicle 10 is simply provided as an example of a type of system configured to be implemented and / or controlled using software developed according to the principles of this disclosure.

[0019] Vehicle 10 includes a body 12 and an engine hood 14. A passenger compartment 18 is at least partially defined by the body 12. Another portion of the body 12 defines an engine compartment 20. The engine hood 14 is movably connected to a portion of the body 12 such that when the engine hood 14 is in a first position or open position, the engine hood 14 provides access to the engine compartment 20, and when the engine hood 14 is in a second position or closed position, the engine hood 14 covers the engine compartment 20. In some embodiments, the engine compartment 20 may be located at the rear of the vehicle 10, rather than as typically shown.

[0020] The passenger compartment 18 may be located behind the engine compartment 20, but in embodiments where the engine compartment 20 is located at the rear of the vehicle 10, the passenger compartment 18 may be located in front of the engine compartment 20. The vehicle 10 may include any suitable propulsion system, including an internal combustion engine, one or more electric motors (e.g., an electric vehicle), one or more fuel cells, a hybrid propulsion system (e.g., a hybrid vehicle, including a combination of an internal combustion engine and one or more electric motors), and / or any other suitable propulsion system.

[0021] In some embodiments, vehicle 10 may include a gasoline or gasoline-fueled engine, such as a spark-ignition engine. In some embodiments, vehicle 10 may include a diesel-fueled engine, such as a compression-ignition engine. Engine compartment 20 houses and / or encloses at least some components of the propulsion system of vehicle 10. Additionally or alternatively, propulsion control devices, such as accelerator actuators (e.g., accelerator pedal), brake actuators (e.g., brake pedal), steering wheel, and other such components are disposed in passenger compartment 18 of vehicle 10. The propulsion control devices may be actuated or controlled by the operator of vehicle 10 and may be directly connected to respective components of the propulsion system (e.g., throttle, brakes, axles, vehicle transmission, etc.). In some embodiments, the propulsion control devices may transmit signals to a vehicle computer (e.g., drive-by-wire), which in turn may control the respective propulsion components of the propulsion system. Thus, in some embodiments, vehicle 10 may be an autonomous vehicle.

[0022] In some embodiments, vehicle 10 includes a transmission communicated with a crankshaft via a flywheel, clutch, or hydraulic coupling. In some embodiments, the transmission includes a manual transmission. In some embodiments, the transmission includes an automatic transmission. In the case of an internal combustion engine or hybrid vehicle, vehicle 10 may include one or more pistons that cooperate with the crankshaft to generate force, which is transmitted through the transmission to one or more shafts that rotate wheels 22. When vehicle 10 includes one or more electric motors, a vehicle battery and / or fuel cell provide energy to the electric motors to rotate wheels 22.

[0023] Vehicle 10 may include an automated vehicle propulsion system (e.g., cruise control, adaptive cruise control, automatic braking control, other automated vehicle propulsion systems, or combinations thereof). Vehicle 10 may be an automated or semi-automated vehicle, or other suitable type of vehicle. Vehicle 10 may include more or fewer features than generally shown and / or disclosed herein.

[0024] In some embodiments, vehicle 10 may include an Ethernet component 24, a Controller Area Network (CAN) bus 26, a Media-Oriented System Transport (MOST) component 28, a FlexRay component 30 (e.g., a brake-by-wire system), and a Local Interconnect Network (LIN) component 32. Vehicle 10 may use the CAN bus 26, MOST 28, FlexRay component 30, LIN 32, other suitable network or communication systems, or combinations thereof, to transmit various information from sensors, such as those inside or outside the vehicle, to various processors or controllers, such as those inside or outside the vehicle. Vehicle 10 may include more or fewer features than generally shown and / or disclosed herein.

[0025] In some embodiments, the vehicle 10 may include a steering system, such as an EPS system, a steer-by-wire system (e.g., which may include or communicate with one or more controllers that control components of the steering system without using a mechanical connection between the steering wheel and the wheels 22 of the vehicle 10), a hydraulic steering system (e.g., which may include a magnetic actuator integrated into a valve assembly of the hydraulic steering system), or other suitable steering systems.

[0026] A steering system may include an open-loop feedback control system or mechanism, a closed-loop feedback control system or mechanism, or a combination thereof. The steering system may be configured to receive various inputs, including but not limited to steering wheel position, input torque, one or more wheel positions, other suitable inputs or information, or a combination thereof.

[0027] Additionally or alternatively, inputs may include steering wheel torque, steering wheel angle, motor speed, vehicle speed, estimated motor torque command, other suitable inputs, or combinations thereof. The steering system may be configured to provide steering functionality and / or control to the vehicle 10. For example, the steering system may generate auxiliary torque based on various inputs. The steering system may be configured to selectively control the motor of the steering system using the auxiliary torque to provide steering assistance to the operator of the vehicle 10.

[0028] In some embodiments, the vehicle 10 includes one or more controllers, such as controller 100, as... Figure 1B As generally shown. Controller 100 may correspond to a steering system controller. Controller 100 may include any suitable controller, such as an electronic control unit or other suitable controller. Controller 100 may be configured to control various functions, such as those of the steering system and / or various functions of the vehicle 10. Controller 100 is simply provided as an example of a type of controller or device configured to be implemented and / or controlled using software developed according to the principles of this disclosure.

[0029] Controller 100 may include processor 102 and memory 104. Processor 102 may include any suitable processor, such as those described herein. Additionally or alternatively, controller 100 may include any suitable number of processors in addition to or besides processor 102. Memory 104 may include a single disk or multiple disks (e.g., hard disk drives) and includes a storage management module that manages one or more partitions within memory 104. In some embodiments, memory 104 may include flash memory, semiconductor (solid-state) memory, etc. Memory 104 may include random access memory (RAM), read-only memory (ROM), or a combination thereof. Memory 104 may include instructions that, when executed by processor 102, cause processor 102 to control at least various aspects of vehicle 10. Additionally or alternatively, memory 104 may include instructions that, when executed by processor 102, cause processor 102 to perform functions associated with the systems and methods described herein.

[0030] The controller 100 may receive one or more signals from various measuring devices or sensors 106, which indicate sensed or measured characteristics of the vehicle 10. Sensors 106 may include any suitable sensors, measuring devices, and / or other suitable mechanisms. For example, sensors 106 may include one or more torque sensors or devices, one or more steering wheel position sensors or devices, one or more motor position sensors or devices, one or more position sensors or devices, other suitable sensors or devices, or combinations thereof. One or more signals may indicate steering wheel torque, steering wheel angle, motor speed, vehicle speed, other suitable information, or combinations thereof.

[0031] As used herein, "controller" can refer to a hardware module or component including one or more processors or microcontrollers, memory, sensors, one or more actuators, communication interfaces, etc., any part of which can be collectively referred to as "circuit". As described herein, the various functions and steps performed by a given controller, control circuit, etc., can be performed jointly by multiple controllers, processors, etc. For example, a processor, processing device, controller, control circuit, etc., "configured to perform" can refer to a single processor, processing device, controller, etc., configured to simultaneously perform A and B, or it can refer to a first processor, processing device, controller, etc., configured to perform A and a second processor, processing device, controller, etc., configured to perform B. For the sake of brevity, "control circuit configured to perform A and B" can refer to one or more processors, processing devices, controllers, etc., collectively configured to perform A and B.

[0032] Software design and integration processes (e.g., software for the implementation of vehicle 10 and / or components of vehicle 10, software for the manufacture of vehicle 10, etc.) are typically complex, lengthy, and inefficient. For example, Figure 1C As shown, a traditional embedded software development process 120 involves multiple manual inputs, steps, etc., developed by multiple individuals / entities (e.g., software, system, or design engineers, programmers, etc.) on their respective computing devices and delivering deliverables to each other. This necessitates extensive coordination between entities, resulting in lengthy development cycles and sometimes even cumbersome development. For example, the first person or entity (e.g., the software architect shown in 122) defines the outline of a software component and how that component integrates into the larger architecture of a separate software project (e.g., the software architecture diagram shown in 124). Conversely, one or more second entities develop the functionality of the software component (e.g., the individual engineers shown in 126), and a third entity (e.g., the software integrator shown in 128) integrates the software component into the project (e.g., schematically shown as software documentation in 130), as defined by the software architect 122. This process occurs without a clear or robust system for sharing files among team members or providing traceability to each other or other parties within the organization. Furthermore, the process may be delayed at different points or steps, such as by the amount of time required to upload and download parts or all of the software project. As another example, the process may fail for various reasons, such as the lack of a general change log for the project.

[0033] Furthermore, there is a limit to the amount of parallel work that can be completed within an organization. For example, current software integration processes require proprietary software tools with high licensing costs. Therefore, the number of engineers holding the appropriate licenses is kept to a minimum, which limits the amount of work that can be completed across all projects within the organization.

[0034] The software design and integration systems and methods based on the principles of this disclosure (e.g., software implemented by vehicle 10 and / or components of vehicle 10, software for manufacturing vehicle 10, etc.) facilitate embedded software development by implementing continuous integration pipeline technology, as described in more detail below.

[0035] Figure 2An exemplary embedded software development process 200 implementing a continuous integration pipeline 204 and related technologies according to this disclosure is illustrated. Users (e.g., software designers and / or other engineers, as shown in 206) contribute their respective contributions (e.g., individual software components) to process 200 via pipeline 204 (e.g., via a corresponding processing device, computing device, associated user interface, etc., shown in 208). Pipeline agents (e.g., implemented by one or more processors, computing devices, etc., shown in 210) execute different processes to integrate the individual components of the respective engineers to publish integration results 212 (e.g., software architecture diagrams, calibration files, software binaries, etc.).

[0036] Figure 3 An exemplary pipeline process 300 for performing changes to an independent software component, based on the principles of this disclosure, is generally illustrated. For example, if a user is designing an independent software component, as shown in 302, when changes are committed to the component's implementation codebase (e.g., a Git repository), the server automatically pulls the latest changes to the design (e.g., the Matlab design of the software component), automatically codes the software component, generates a component specification file (e.g., a .arxml file generated using a metadata codebase (e.g., a data dictionary (DataDict)), which is an exemplary standard file for component specifications and can be used with various development tools), inserts the source code of the new changes into the integration project, compiles it, and commits it to the integration project's codebase upon success (as shown in 304). As used herein, "server" can correspond to one or more local or remote computing devices, cloud computing systems, etc., which can be provided by... Figure 2 The computing device 210 is schematically represented.

[0037] In one example, process 300 includes using one or more processors: receiving an instruction to make changes to a first software component in a plurality of independent software products (e.g., triggered by changes submitted and pushed to an implementation codebase); in response to the instruction, automatically updating the architecture definition associated with the first software component based on the changes made to the first software component; updating the architecture of the software product based on the changes made to the first software component; compiling the software product; and releasing the build artifacts associated with the software product.

[0038] Figure 4A and Figure 4B The diagram generally illustrates methods for implementing architectural changes (e.g., with) based on the principles of this disclosure. Figure 3 The exemplary pipeline processes 400 and 402 (comparing changes to individual components as described above) illustrate this. By hosting the code of software components in their own dedicated, separate code repositories, software components can be viewed as modular units that can be plugged into one or more integration projects. Therefore, combining the above... Figure 3 The automated coding pipeline described in detail allows changes to components to be automatically distributed across multiple integration projects. This enables designers to have multiple compiled binaries containing their changes available for testing across multiple projects and product lines within minutes. This is a significant improvement over the traditional process where component designers make changes and send them to integrators (typically via instant messaging or email, rather than through a central codebase with robust tracking capabilities). The integrators then automatically code the changes on their local computing devices, manually add the code to all necessary integration projects, and manually trigger compilation. This process also greatly improves traceability, with a message for each change and a list of people who made the changes in a location accessible to all users in the codebase.

[0039] It also provides support for changes that directly impact the software project architecture. By defining the project's architecture in its dedicated codebase, which is directly linked to the integration project, changes made to the architecture codebase can trigger changes in the integration project (as shown in 404). Similar to the auto-coding pipeline above, a different pipeline is triggered when a commit is made to the architecture codebase. In this pipeline, the server automatically pulls the latest version of the architecture specification (as shown in 410), and then parses all component specification (e.g., .arxml) files in the integration project to obtain the current state of the project architecture (as shown in 412). The current architecture is then compared with the changed / newly added architecture (as shown in 414) to obtain a change list. The change list is used to improve the overall efficiency of the pipeline, ensuring that only the necessary steps are needed when code generation is performed later in the process.

[0040] If a component is included in a new architecture that does not currently exist in the integration project, all available component codebases are checked first. If the requested component is found, its codebase is added as a submodule to the broader integration project codebase, creating a link that will allow the aforementioned autocoding pipeline to work for the project, and the component's source code is added to the integration project. If there is no existing codebase for the component in the source control system, a new codebase is created based on the specifications in the newly added architecture. This newly created codebase contains everything the component owner needs to develop their component: the component's initial .arxml file, a template Matlab model with autocoding capabilities, a template source file containing empty function definitions of the component's runnable object, and the established pipeline (which autocodes the component on the server when submitted to the newly created component). This newly created component is also added to the integration project, and all autocoding pipelines are automatically configured. 416 schematically illustrates the above process associated with adding a new component.

[0041] As shown in 418, any differences in port mappings (e.g., how data flows between different software components) are detected, and the script automatically modifies various .arxml files in the integration project that involve port mappings. As shown in 420, changes to task mappings (the order in which functions of all different software components are called) are handled similarly. Furthermore, as shown in 422, if components are removed from the project's architecture, the script removes these components from the integration project. As shown in 424, modified components (e.g., components that are not new but have been modified / changed) are updated.

[0042] After completing the above steps, the tool uses existing tools to generate source code (e.g., ASIL-D level source code) based on the project's .arxml files, which have been edited to meet the specified architecture; generates C file templates; generates the runtime environment, etc. (as shown in 430); and finally compiles the project and commits the changes to the integration project's codebase (as shown in 432). Traditionally, the process of creating a new component and adding it to an integration project requires at least two, usually three, or possibly more engineers, and at least an hour of work (if everything goes smoothly). These pipelines automate the entire process in less than ten minutes, requiring only one engineer to provide input. Furthermore, the process creates the component in a new development environment, allowing it to be easily added to other projects and its changes distributed across all projects. In addition, the need for multiple licenses for software tools that generate ASIL-D source code is reduced, as only one license is required for the server, rather than numerous users within the organization.

[0043] These scripts provide a more streamlined and efficient development process and environment. By offloading a significant amount of software integration work to the server, overall development time is greatly reduced, while the need for expensive licenses for widely relied-upon software tools is significantly lowered. Furthermore, work that previously required multiple engineers (with little or no traceability) can now be completed by a single person, and all users have easy access to the complete changelog. Moreover, it allows for a more flexible environment, enabling easier and more automated distribution to multiple products.

[0044] A key feature of the principles of this disclosure stems from the process described herein and the development methodology implemented therein. This approach to developing embedded software is entirely different from traditional methods used across multiple industries, offering greater flexibility and development efficiency for all stakeholders. By using a modular approach and allowing for easier application of changes to multiple projects and product lines, the impact of a single change is increased by orders of magnitude. The combination of many different parts—e.g., pipelines triggered at a single commit, organizing projects into a series of submodules shared among their peers, automatic coding of individual components, and integration of multiple types of software changes at the individual component and architectural levels—creates a unified process with remarkable improvements over traditional development processes.

[0045] Figure 5 An exemplary computing device, configured to implement various aspects of a pipelined process according to the principles of this disclosure, is generally illustrated. The computing device 500 may be, for example, a server computer, a controller, or any other similar computing device capable of processing data. Figure 5 In the example implementation, computing device 500 includes a hardware processor 502 and a machine-readable storage medium 504. Computing device 500 may include one or more additional components, which are not shown for the sake of simplicity. For example, computing device 500 may include a bus or other communication mechanism for transmitting information, and one or more additional hardware processors coupled to the bus for processing information.

[0046] Hardware processor 502 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices adapted to retrieve and execute instructions stored in machine-readable storage medium 504. Hardware processor 502 may fetch, decode, and execute instructions to control processes or operations for burst preloading based on an estimate of available bandwidth. As an alternative to or supplement to retrieving and executing instructions, hardware processor 502 may include one or more electronic circuits comprising electronic components for the function of executing one or more instructions, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits.

[0047] Machine-readable storage media (e.g., machine-readable storage media 504) can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Therefore, machine-readable storage media 504 can be, for example, random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, machine-readable storage media 504 can be a non-transitory storage medium, where the term "non-transitory" does not include transient propagation signals.

[0048] As described in detail below, machine-readable storage medium 504 can be encoded with executable instructions (e.g., instruction 506). When stored in storage medium accessible to hardware processor 502, these instructions cause computing device 500 to become a special-purpose machine customized to perform the operations specified in the instructions. Specifically, instruction 506 may correspond to... Figure 3 , Figure 4A and Figure 4B The steps of the example process shown.

[0049] In the example, hardware processor 502 can perform the following operation by executing instruction 506. Figure 3 The illustrated process is as follows: Automatically encode the software model (e.g., the software model of the independent software components of a software product) based on user changes to individual software components; copy the automatically encoded files (e.g., C and H files) to the implementation codebase; generate component specification files (e.g., create / modify .arxml files from the DataDict codebase); commit and push changes to the implementation codebase; receive instructions to make changes to the first software component in multiple independent software products (e.g., triggered by changes committed and pushed to the implementation codebase); in response to the instructions, switch the architecture data codebase to the correct branch and pull the changes; switch all components to the branch specified in the architecture; pull changes for all components in the software product; selectively / automatically update the architecture definition associated with the first software component based on the changes made to the first software component; update the architecture of the software product based on the changes made to the first software component; compile the software product; commit and push integration project changes; generate the default system configuration project / phase (SCP); and release the build artifacts associated with the software product.

[0050] In other examples, hardware processor 502 can execute instruction 506 to perform... Figure 4A and Figure 4B The process is shown below.

[0051] In some examples, computing device 500 may be coupled to a display for showing information to a computer user. One or more input devices may be provided for transmitting information and command selections to hardware processor 502. Computing device 500 may also include a user interface module implementing a GUI, which may be stored as executable software code executed by the computing device in a mass storage device. As an example, this module and other modules may include components such as software components, object-oriented software components, class components and task components, processes, functions, properties, flows, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0052] Generally speaking, the terms "component," "engine," "system," "database," and "data storage" used in this document can refer to logic contained in hardware or firmware, or to a collection of software instructions that may have entry and exit points and are written in a programming language such as Java, C, or C++. Software components can be compiled and linked into executable programs and installed in dynamic link libraries, or can be written in interpreted programming languages ​​such as BASIC, Perl, or Python. It should be understood that software components can be invoked from other components or themselves, and / or can be invoked in response to detected events or interrupts. Software components configured to execute on a computing device can be provided on computer-readable media (such as optical discs, digital video discs, flash drives, disks, or any other tangible media) or as digital downloads (and may be initially stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code can be stored, in part or in whole, on a memory device executing the computing device for execution by the computing device. Software instructions can be embedded in firmware (such as EPROM). It should also be understood that hardware components may include connected logic units (e.g., gates and flip-flops), and / or may include programmable units (e.g., programmable gate arrays or processors).

[0053] The computing device 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, combined with a computer system, enables or programs the computing device 500 to become a dedicated machine. According to one example of the disclosed techniques, the computing device 500 executes the techniques of this invention in response to a hardware processor 502 executing one or more sequences of one or more instructions contained in memory (e.g., machine-readable storage medium 504). Execution of the instruction sequence causes the hardware processor 502 to perform the flow steps described herein. In alternative examples, hardwired circuitry may be used in place of or in combination with software instructions.

[0054] As used herein, the term "non-transitory media" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-transitory media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks. Volatile media include dynamic memory. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs, and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or memory enclosures, and networked versions thereof.

[0055] Non-transitory media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transitory media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the conductors that form the bus. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0056] The computing device 500 may also include a communication interface, such as a network interface providing bidirectional data communication coupled to one or more network links connected to one or more local networks (e.g., network 106). For example, the communication interface may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, the communication interface may be a Local Area Network (LAN) card to provide data communication connectivity to a LAN-compatible network (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, the communication interface transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0057] Network links typically provide data communication to other data devices over one or more networks. For example, a network link can provide a connection to a host or a data device operated by an Internet Service Provider (ISP) through a local network. ISPs, in turn, provide data communication services through the global packet data communication network now commonly referred to as the "Internet." Both local area networks (LANs) and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network links and through communication interfaces, are example forms of transmission media that transmit digital data to and from computing device 500.

[0058] Computing device 500 can send messages and receive data (including program code) via networks, network links, and communication interfaces. In the Internet example, the server can send application request code via the Internet, ISP, local network, and communication interfaces.

[0059] The received code can be executed by the hardware processor 502 when it is received, and / or stored in a storage device or other non-volatile memory for subsequent execution.

[0060] Each process, method, and algorithm described in the preceding sections can be implemented in a code component and fully or partially automated by that code component, executed by one or more computing device systems or computer processors comprising computer hardware. The one or more computer systems or computer processors can also operate to support the execution of related operations in a “cloud computing” environment or as “Software as a Service” (SaaS). These processes and algorithms can be implemented, partially or entirely, in dedicated circuitry. The various features and processes described above can be used independently of each other or can be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process boxes may be omitted in some implementations. The methods and processes described herein are not limited to any particular order, and the boxes or states associated with them can be executed in other suitable orders, or can be executed in parallel, or in some other manner. Boxes or states can be added to or removed from the disclosed examples. The execution of certain operations or processes can be distributed across computer systems or computer processors, residing not only on a single machine but also deployed across multiple machines.

[0061] The circuits used herein can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be used to compose the circuits. In implementation, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be partially or wholly shared among one or more circuits. Even if various features or functional elements can be described or claimed as discrete circuits individually, these features and functions can be shared among one or more common circuits, and such description should not require or imply the need for discrete circuits to implement such features or functions. Where the circuits are implemented wholly or partially in software, such software can be implemented to operate in conjunction with a computing or processing system (e.g., computing device 500) capable of performing the functions described herein.

[0062] The foregoing discussion is intended to illustrate the principles and various embodiments of this disclosure. Once the foregoing disclosure is fully understood, many variations and modifications will become apparent to those skilled in the art. The following claims are intended to be construed as encompassing all such variations and modifications.

[0063] The term “example” as used herein means used as an example, instance, or illustration. Any aspect or design described herein as an “example” is not necessarily to be construed as preferred or superior to other aspects or designs. Rather, the term “example” is used to present concepts in a specific manner. As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise stated or clear from the context, “X comprises A or B” is intended to mean any natural inclusive arrangement. That is, if X comprises A; X comprises B; or X comprises A and B, then “X comprises A or B” is satisfied in any of the foregoing cases. Furthermore, the articles “a” and “an” as used in this application and the appended claims should generally be interpreted as meaning “one or more” unless otherwise stated or clearly pointed to from the context in the singular form. Additionally, the use of the terms “an implementation” or “one embodiment” throughout does not refer to the same embodiment or implementation unless so described.

Claims

1. A method for performing integrated software development on a software product comprising multiple independent software components, the method comprising using one or more processors to perform the following operations: Receive an instruction to make changes to a first software component among the plurality of independent software products; In response to the instruction, the architecture definition associated with the first software component is automatically updated based on the changes made to the first software component; The architecture of the software product is updated based on changes made to the first software component; Compile the software product; and Publish the build artifacts associated with the software product.

2. The method according to claim 1, further comprising: The instruction is automatically generated in response to the change being submitted to the implementation codebase associated with the first software component.

3. The method according to claim 1, further comprising: The first software component is automatically coded based on the changes.

4. The method according to claim 1, further comprising: Generate a specification component file for the first software component.

5. The method according to claim 4, further comprising: Determine whether the specification component file has been changed, and update the architecture based on the determination that the specification component file has been changed.

6. The method according to claim 1, further comprising: Determine whether to make a change to any one of the plurality of independent software components; as well as In response to determining that a change has been made to any one of the plurality of independent software components, the architecture of the software product is updated based on the change made to any one of the plurality of independent software components.

7. The method of claim 1, wherein the software product corresponds to embedded software of a vehicle's steering system.

8. A system for performing integrated software development on a software product comprising multiple independent software components, the system comprising: Memory that stores instructions; as well as One or more processors are configured to execute the instructions, wherein executing the instructions causes the system to perform the following operations: Receive an instruction to make changes to a first software component among the plurality of independent software products; In response to the instruction, the architecture definition associated with the first software component is automatically updated based on the changes made to the first software component; The architecture of the software product is updated based on changes made to the first software component; Compile the software product; and Publish the build artifacts associated with the software product.

9. The system of claim 8, wherein executing the instructions further causes the system to automatically generate the instructions in response to the change being submitted to the implementation codebase associated with the first software component.

10. The system of claim 8, wherein executing the instructions further causes the system to: automatically encode the first software component based on the change.

11. The system of claim 8, wherein executing the instructions further causes the system to: generate a specification component file for the first software component.

12. The system of claim 11, wherein executing the instructions further causes the system to: determine whether the specification component file has been changed, and update the architecture based on the determination that the specification component file has been changed.

13. The system of claim 8, wherein executing the instructions further causes the system to perform the following operations: Determine whether to make changes to any of the plurality of independent software components; and In response to determining that a change has been made to any one of the plurality of independent software components, the architecture of the software product is updated based on the change made to any one of the plurality of independent software components.

14. The system of claim 8, wherein the software product corresponds to embedded software of a vehicle steering system.

15. A method for performing integrated software development on a software product comprising multiple independent software components, the method comprising using one or more processors to perform the following operations: Receive instructions to make changes to the architecture codebase associated with the software product; In response to the instruction, the current architecture of the software product is compared with a new architecture, the new architecture corresponding to changes made to the architecture codebase; Based on the comparison, the software product is automatically modified in at least one of the following ways: (i) adding new software components to the software product, (ii) removing existing components from the software product, and (iii) modifying existing components of the software product; Compile the software product; and Publish the build artifacts associated with the software product.

16. The method of claim 15, wherein automatically modifying the software product comprises: Generate at least one of the port mappings and task mappings associated with the change.

17. The method of claim 15, further comprising: Based on the changes, generate at least one C file template and runtime environment.

18. The method of claim 15, wherein adding the new software component comprises: Generate component specification files for the new software components.

19. The method of claim 15, further comprising: Detect changes made to the architecture codebase and automatically generate the indication based on the detection of the changes.

20. The method of claim 15, wherein the software product corresponds to embedded software of a vehicle's steering system.

Images