Development of embedded software using continuous integration by a pipeline agent

Abstract

A method for performing integrated software development of a software product comprising a plurality of individual software components includes, using one or more processors, receiving a notification that a change has been made to an initial software component of the plurality of individual software products, in response to the notification, automatically updating an architecture definition associated with the initial software component based on the change made to the initial software component, updating an architecture of the software product based on the change made to the initial software component, compiling the software product, and publishing build artifacts associated with the software product.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS This application claims the benefit of preliminary US application No. 63 / 743,011, filed on January 8, 2025. The entire disclosure of the above-mentioned application is incorporated herein by reference. TECHNICAL AREA This disclosure concerns a software architecture for developing and integrating software applications. BACKGROUND OF THE INVENTION A vehicle, such as a car, truck, sport utility vehicle (SUV), crossover, minivan, personal watercraft, aircraft, all-terrain vehicle, motorhome, or other suitable form of transport, typically includes a steering system, such as an electronic power steering (EPS) system, a steer-by-wire (SbW) system, a hydraulic steering system, or another suitable steering system. The steering system of such a vehicle generally controls various aspects of vehicle steering, including providing steering assistance to a vehicle operator, controlling the vehicle's steerable wheels, and the like. Steering and other automotive systems require the development, integration, and implementation of various software components and applications. BRIEF SUMMARY OF THE INVENTION The present disclosure relates to generally integrated software development processes. A method for performing integrated software development of a software product comprising a plurality of individual software components includes, using one or more processors, receiving a notification that a change has been made to an initial software component of the plurality of individual software products, in response to the notification, automatically updating an architecture definition associated with the initial software component based on the change made to the initial software component, updating an architecture of the software product based on the change made to the initial software component, compiling the software product, and publishing build artifacts associated with the software product. Other aspects include systems, computing devices, one or more processors, etc., configured to perform functions related to the procedures described herein. BRIEF DESCRIPTION OF THE DRAWINGS The disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It is emphasized that, in accordance with common practice, the various features of the drawings are not to scale. On the contrary, the dimensions of the various features have been arbitrarily enlarged or reduced for clarity. Fig. 1A illustrates generally a vehicle according to the principles of the present disclosure. Fig. 1B illustrates generally a controller according to the principles of the present disclosure. Fig. 1C illustrates generally a development process of embedded software. Fig. 2 illustrates generally an exemplary development process of embedded software that implements a continuous integration pipeline and related techniques, according to the principles of the present disclosure.Figure 3 illustrates a general example pipeline process for changes to an individual software component according to the principles of this disclosure. Figures 4A and 4B illustrate a general example pipeline process for architectural changes according to the principles of this disclosure. Figure 5 illustrates a general example computing device configured to implement various aspects of the pipeline process according to the principles of this disclosure. DETAILED DESCRIPTION The following discussion is directed toward various embodiments of the disclosure. Although one or more of these embodiments may be preferred, the disclosed embodiments should not be interpreted or otherwise used as limiting the scope of the disclosure, including the claims. Furthermore, a person skilled in the art will understand that the following description has broad application, and the discussion of any one embodiment is intended only as an example of that embodiment and should not imply that the scope of the disclosure, including the claims, is limited to that embodiment. The systems and methods described in this disclosure are configured to facilitate the development of embedded software (e.g., the development of a software product, file, infrastructure, etc., comprising a multitude of individual software components) by implementing continuous integration pipeline techniques. For example, a set of scripts is implemented to leverage the functionality of continuous integration pipelines (Microsoft Azure Pipelines, GitLab, Jenkins, etc.) to automate parts of the software development process. Several distinct processes or procedures are automated based on the actions of one or more users. These diverse processes are executed using a pipeline agent configured to perform various integration steps and publish / output the results of the integration. Figure 1A illustrates a vehicle 10 in general, according to the principles of this disclosure. The vehicle 10 may be any suitable vehicle, such as a car, a truck, a sport utility vehicle (SUV), a minivan, a crossover, any other passenger vehicle, any suitable commercial vehicle, or any other suitable vehicle. Although the vehicle 10 is illustrated as a wheeled passenger vehicle for use on roads, the principles of this disclosure may be applied to other vehicles, such as airplanes, boats, trains, drones, or other suitable vehicles. The vehicle 10 is provided merely as an example of a type of system configured to implement and / or be controlled by software developed according to the principles of this disclosure. The vehicle 10 comprises a vehicle body 12 and an engine hood 14. A passenger compartment 18 is defined, at least in part, by the vehicle body 12. Another section of the vehicle body 12 defines an engine compartment 20. The engine hood 14 can be movably attached to a section of the vehicle body 12 such that the engine hood 14 provides access to the engine compartment 20 when it is in a first or open position, and covers the engine compartment 20 when it is in a second or closed position. In some embodiments, the engine compartment 20 may be located at a rear section of the vehicle 10, unlike the generally illustrated one. The passenger compartment 18 can be located behind the engine compartment 20, but in embodiments where the engine compartment 20 is located at the rear section of the vehicle 10, it can be located in front of the engine compartment 20. The vehicle 10 can comprise 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) with a combination of an internal combustion engine, one or more electric motors, and / or any other suitable propulsion system. In some embodiments, the vehicle 10 may include a gasoline or spark-ignition engine, such as a spark-ignition engine. In some embodiments, the vehicle 10 may include a diesel engine, such as a compression-ignition engine. The engine compartment 20 accommodates and / or encloses at least some components of the vehicle 10's drive system. Additionally or alternatively, drive control devices, such as an accelerator pedal actuator (e.g., an accelerator pedal), a brake actuator (e.g., a brake pedal), a steering wheel, and other such components, are arranged in the passenger compartment 18 of the vehicle 10. The drive control devices can be actuated or controlled by an operator of the vehicle 10 and can be directly connected to corresponding components of the drive system, such as a throttle valve, a brake, a vehicle axle, a vehicle transmission, and the like.In some embodiments, the drive control units can communicate signals to a vehicle computer (e.g., via a wired connection), which in turn can control the corresponding drive component of the drive system. Thus, in some embodiments, the vehicle 10 can be an autonomous vehicle. In some embodiments, the vehicle 10 includes a transmission that is connected to a crankshaft via a flywheel, a clutch, or a fluid 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 a hybrid vehicle, the vehicle 10 may include one or more pistons that work in concert with the crankshaft to generate power that is transmitted through the transmission to one or more axles, thereby rotating wheels 22. If the vehicle 10 includes one or more electric motors, a vehicle battery and / or a fuel cell provides energy to the electric motors to rotate the wheels 22. Vehicle 10 may include automatic vehicle propulsion systems, such as cruise control, adaptive cruise control, automatic braking control, other automatic vehicle propulsion systems, or a combination thereof. Vehicle 10 may be an autonomous or semi-autonomous vehicle, or another suitable type of vehicle. Vehicle 10 may include additional or fewer features than those generally illustrated and / or disclosed herein. In some embodiments, the vehicle 10 may include an Ethernet component 24, a Controller Area Network (CAN) bus 26, a Media-Oriented Systems Transport (MOST) component 28, a FlexRay component 30 (e.g., a brake-by-wire system and the like), and a Local Interconnect Network (LIN) component 32. The vehicle 10 may use the CAN bus 26, the MOST 28, the FlexRay component 30, the LIN 32, other suitable networks or communication systems, or a combination thereof, to transmit various pieces of information from, for example, sensors inside or outside the vehicle to, for example, various processors or controllers inside or outside the vehicle. The vehicle 10 may include additional or fewer features than those generally illustrated and / or disclosed herein. In some embodiments, the vehicle 10 may include a steering system, such as an EPS system, a steer-by-wire steering system (which may, for example, include or communicate with one or more controllers that control the components of the steering system without the use of a mechanical connection between the steering wheel and the wheels 22 of the vehicle 10), a hydraulic steering system (which may, for example, include a magnetic actuator integrated into a valve assembly of the hydraulic steering system), or another suitable steering system. The 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 road wheel positions, other suitable inputs or information, or a combination thereof. Additionally or alternatively, the inputs may include steering wheel torque, steering wheel angle, engine speed, vehicle speed, an estimated engine torque command, another suitable input, or a combination thereof. The steering system may be configured to provide a steering function and / or control to the vehicle 10. For example, the steering system may generate an assist torque based on the various inputs. The steering system may be configured to selectively control a motor of the steering system using the assist torque to provide steering assistance to the operator of the vehicle 10. In some embodiments, the vehicle 10 comprises one or more controllers, such as controller 100, as generally illustrated in Fig. 1B. The controller 100 may correspond to a steering system controller. The controller 100 may comprise any suitable controller, such as an electronic control unit or other suitable controller. The controller 100 may be configured to control, for example, the various functions of the steering system and / or various functions of the vehicle 10. The controller 100 is provided merely as an example of a type of controller or device configured to implement and / or be controlled by software developed according to the principles of this disclosure. The controller 100 can comprise a processor 102 and a memory 104. The processor 102 can comprise any suitable processor, such as those described herein. Additionally or alternatively, the controller 100 can comprise any suitable number of processors in addition to the processor 102, or a processor other than the processor 102. The memory 104 can comprise a single disk or a plurality of disks (e.g., hard disks) and includes a memory management module that manages one or more partitions within the memory 104. In some embodiments, the memory 104 can comprise flash memory, solid-state memory, or the like. The memory 104 can comprise random-access memory (RAM), read-only memory (ROM), or a combination thereof.Memory 104 can contain instructions that, when executed by processor 102, cause processor 102 to control at least various aspects of vehicle 10. Additionally or alternatively, memory 104 can contain instructions that, when executed by processor 102, cause processor 102 to perform functions associated with the systems and procedures described herein. The controller 100 can receive one or more signals from various measuring devices or sensors 106 that indicate detected or measured characteristics of the vehicle 10. The sensors 106 can include any suitable sensors, measuring devices, and / or other suitable mechanisms. For example, the sensors 106 can include one or more torque sensors or devices, one or more steering wheel position sensors or devices, one or more engine position sensors or devices, one or more position sensors or devices, other suitable sensors or devices, or a combination thereof. The one or more signals can indicate steering wheel torque, steering wheel angle, engine speed, vehicle speed, other suitable information, or a combination thereof. As used herein, "controller" can refer to a hardware module or assembly comprising one or more processors or microcontrollers, memory, sensors, one or more actuators, a communication interface, etc., any part of which may collectively be referred to as a "circuit." As described herein, respective functions and steps performed by a given controller, control circuit, etc., may be performed collectively by multiple controllers, processors, etc. For example, a processor, processing device, controller, control circuit, etc., that is / are "configured to perform" may refer to a single processor, processing device, controller, etc., configured to perform both A and B, or it may refer to a first processor, processing device, controller, etc., which is / are configured to perform A, and to a second processor, processing device, controller, etc., which is / are configured to perform B. For simplicity, “control circuitry configured to perform A and B” can refer to one or more processors, processing devices, controllers, etc., which are collectively configured to perform A and B. Software design and integration processes (e.g., for software implemented by the vehicle 10 and / or components of the vehicle 10, software used to manufacture the vehicle 10, etc.) are typically complex, lengthy, and inefficient. For example, as shown in Fig. 1C, a conventional embedded software development process 120 involves a multitude of manual inputs, steps, etc., with numerous individuals / entities (e.g., software, systems, or development engineers, programmers, etc.) developing deliverables and passing them to their respective computing devices. Therefore, significant coordination between entities is required, resulting in a lengthy and sometimes cumbersome development cycle. For example, a first person or entity (e.g.,A software architect (as shown in 122) defines an outline of a software component and how the software component fits into the larger architecture of an individual software project (e.g., as a software architecture diagram shown in 124). Conversely, one or more second entities develop the functionality of the software component (e.g., various engineers, as shown in 126), and a third entity (e.g., a software integrator, as shown in 128) integrates the software component into the project (e.g., schematically shown in 130 as a software file), as defined by the software architect in 122. This process occurs without a clear or robust system for sharing files among team members or for providing traceability for each other or others within an organization.Furthermore, this process can be delayed at various points or steps, such as delays caused by the time required to upload and download parts or all of a software project. As another example, the process can fail for various reasons, such as the lack of a common change log for projects. 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 specialized software tools with expensive licensing fees. Therefore, the number of engineers with the necessary licenses is kept to a minimum, which limits the amount of work that can be accomplished across all projects within an organization. Software design and integration systems and procedures (e.g., for software implemented by the vehicle 10 and / or components of the vehicle 10, software used to manufacture the vehicle 10, etc.) according to the principles of the present disclosure facilitate the development of embedded software by implementing continuous integration pipeline techniques, as described in more detail below. Figure 2 shows an exemplary development process 200 of embedded software that implements a continuous integration pipeline 204 and associated techniques according to the present disclosure. Users (e.g., software designers and / or other engineers, as shown in 206) provide respective contributions (e.g., individual software components) to the process 200 via the pipeline 204 (e.g., via respective processing devices, computing devices, associated user interfaces, etc., as shown in 208). A pipeline agent (e.g., implemented by one or more processors, computing devices, etc., as shown in 210) executes different processes to integrate the individual components of the various engineers in order to release integrated results 212 (e.g., a software architecture diagram, calibration files, a software binary, etc.). Figure 3 illustrates a general example pipeline process 300 for making changes to a custom software component according to the principles of this disclosure. For example, if a user is working on the design of a custom software component, then when the changes are committed to an implementation repository (e.g., a Git repository) for that component, as shown in Figure 302, the server automatically pulls the latest changes to the design (e.g., a Matlab design of the software component), automatically autocodes the software component, generates a specification component file (e.g., generates an .arxml file, an exemplary standard file for component specifications that can be used in various development tools), using a repository of metadata, such as...a data dictionary (DataDict)), and inserts the newly modified source code into the integration project, which is then compiled and, if successful, committed to the integration project's repository (as shown in Figure 304). As used herein, the "server" may correspond to one or more local or remote computing devices, a cloud computing system, etc., which may be schematically represented by computing device 210 in Figure 2. In one example, process 300, using one or more processors, includes: receiving a notification that a change has been made to a first software component of the multitude of individual software products (e.g., triggered by changes committed and pushed to the implementation repository); in response to the notification, automatically updating an architecture definition associated with the first software component based on the change made to the first software component; updating an architecture of the software product based on the change made to the first software component; compiling the software product and publishing build artifacts associated with the software product. Figures 4A and 4B illustrate a general example pipeline process 400, 402 for implementing architectural changes (as opposed to changes to an individual component, as described in Figure 3) according to the principles of this disclosure. By hosting the code of the software components in their own individual repositories, the software components can be treated as modular units that can be divided into one or more integration projects. Accordingly, in combination with the autocoding pipelines detailed above in Figure 3, changes to a component can be automatically distributed across multiple integration projects, enabling a designer 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 the component designer makes a change and sends it to the integrator (often via instant message or email rather than a central repository with robust tracking), who then autocodes the change on their local machine and manually adds the code to all necessary integration projects and manually triggers compilation. This process also greatly improves traceability, with every change that has a message and the person who made the change listed in a single location accessible to all users within the repository. Support is also provided for changes that directly affect the architecture of the software project. By defining the project's architecture in a separate repository directly linked to the integration project, we can trigger changes in the integration project based on changes made to the architecture repository (as shown in 404). Similar to the autocoding pipeline mentioned above, another pipeline is triggered when a commit is made to the architecture repository. In this pipeline, the server automatically pulls the latest version of the architecture specification (as shown in 410) and then parses all component specification files (e.g., .arxml files) in the integration project to obtain the current state of the project's architecture (as shown in 412).The current and modified / incoming architectures are then compared (as shown in 414) to obtain a list of changes. This list of changes is used to increase the overall efficiency of the pipeline, ensuring that only the necessary steps are required when code generation is performed later in the process. If a component is included in the new architecture that is not currently present in the integration project, all available component repositories are checked first. If the requested component is found, its repository is added to the broader integration project repository as a sub-module, creating a link that allows the aforementioned autocoding pipelines to work for this project, and the component's source code is added to the integration project. If there is no existing repository for the component in the source control system, a new one is created based on the specifications in the incoming architecture. This newly created repository contains everything a component owner needs to develop their component, including an initial...The components include an arxml file for the component, a template Matlab model with autocoding capabilities, a template source file containing empty function definitions for the component to run, and a pipeline already set up to automatically code the component on commits to the newly created component on the server. This newly created component is also added to the integration project, again automatically configuring all autocoding pipelines. The processes involved in adding a new component are shown schematically in Figure 416. All differences in the port mappings (e.g., how data flows through the various software components) are handled by the script, which automatically makes changes to the various .arxml files within the integration project that deal with port mappings, as shown in Figure 418. A similar process is performed for changes to the task mappings (the order in which functions are called for all the different software components), as shown in Figure 420. Furthermore, if components are removed from the project's architecture, the script removes these components from the integration project, as shown in Figure 422. Modified components (e.g., components that are not new but are modified / changed) are updated, as shown in Figure 424. Once this is done, the tool uses an existing tool to generate source code (e.g., ASIL-D level source code) based on the project's .arxml files, which have been modified to meet the specified architecture. It generates C file templates, creates a runtime environment, and so on (as shown in Figure 430). Finally, it compiles the project and commits the changes to the integration project's repository (as shown in Figure 432). While the process of creating a new component and adding it to an integration project traditionally requires at least two, often three, or possibly more engineers and, if all goes well, at least an hour of work, these pipelines accomplish all of this automatically in less than ten minutes, requiring only a single engineer to provide the input.Furthermore, it creates the component within the new development environment, making it easy to add it to other projects and distribute changes across all projects. Additionally, there is a reduced need for multiple licenses for the software tools that generate the ASIL-D source code, as only the server needs a set of licenses, rather than numerous users throughout the organization. These scripts provide a much more rational and efficient development process and environment. By offloading the majority of software integration work to the server, overall development time is significantly reduced, while the need for expensive licenses for the software tools we rely on is considerably diminished. Furthermore, work that previously required multiple engineers with little to no traceability can now be completed by a single person with a complete change log readily accessible to all users. This also enables a more flexible environment, allowing changes to be easily and automatically distributed across multiple products. A key feature of the principles of this disclosure stems from the process described herein and the development methodology it enables. This means of developing embedded software differs fundamentally from what is traditionally used across multiple industries, and it allows for greater flexibility and development efficiency for all involved. By employing a modular approach and enabling changes to be easily applied across multiple projects and product lines, it increases the impact of an individual change by several orders of magnitude. The combination of many different parts (e.g.,The pipelines triggered by individual commits, the organization of projects as a series of sub-modules shared by their peers, the auto-coding of individual components, and the integration of multiple types of software changes both at the individual component and at the architectural level create a singular process with incredible improvements over the traditional development process. Figure 5 illustrates a general example computing device configured to implement various aspects of the pipeline process according to the principles of this disclosure. The computing device 500 can, for example, be a server computer, a controller, or any other similar computing device capable of processing data. In the example implementation of Figure 5, the computing device 500 includes a hardware processor 502 and a machine-readable storage medium 504. The computing device 500 may include one or more additional components, not shown, to simplify the illustration of the computing device 500. For example, the 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. The Hardware Processor 502 can be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices capable of retrieving and executing instructions stored in the machine-readable memory medium 504. The Hardware Processor 502 can retrieve, decode, and execute instructions to control processes or burst-preload operations for estimating available bandwidth. Alternatively or in addition to retrieving and executing instructions, the Hardware Processor 502 can include one or more electronic circuits containing electronic components for performing the functionality of one or more instructions, such as a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other electronic circuits. A machine-readable storage medium, such as the 504 machine-readable storage medium, can be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the 504 machine-readable storage medium can be, for example, random-access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, and the like. In some examples, the 504 machine-readable storage medium can be a non-transient storage medium, the term "non-transient" encompassing non-transient propagating signals. As described in detail below, the machine-readable storage medium 504 can be encoded with executable instructions, such as the instructions 506. Such instructions, when stored on storage media accessible to the hardware processor 502, make the computing device 500 a specialized machine, custom-designed to perform the operations specified in the instructions. In particular, the instructions 506 can correspond to steps of the example processes shown in Fig. 3, Fig. 4A, and Fig. 4B. In one example, the hardware processor 502 can perform the process shown in Fig. 3 by executing instructions 506 to: autocode a software model (e.g., of a single software component of a software product) based on changes made by a user to a single software component; copy autocoded files (e.g., C and H files) to implementation repositories; generate a component specification file (e.g., create / modify an .arxml file from the DataDict repository); commit and push changes to implementation repositories; and receive notification that a change has been made to a first software component of the multitude of individual software products (e.g.,triggered by changes that are committed and pushed to the implementation repository; in response to the notification, switch the architecture data repository to the correct branch and pull changes; switch all components to the branch specified in the architecture; pull changes for all components in the software product; selectively / automatically update an architecture definition associated with the first software component based on the change made to the first software component; update an architecture of the software product based on the change made to the first software component; compile the software product; commit and push changes to an integration project; create a standard system configuration project / phase (SCP); and publish build artifacts associated with the software product. In other examples, the hardware processor 502 can execute instructions 506 to perform the process shown in Fig. 4A and Fig. 4B. In some examples, the computing device 500 may be coupled with a display for showing information to a computer user. One or more input devices may be provided for transmitting information and command selections to the hardware processor 502. The computing device 500 may also include a user interface module for implementing a GUI, which may be stored in a mass storage device as executable software code that is executed by the computing device. These and other modules may include components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. In general, the terms "component," "engine," "system," "database," "data store," and the like, as used here, can refer to logic embodied in hardware or firmware, or to a collection of software instructions, possibly with inputs and outputs, written in a programming language such as Java, C, or C++. A software component can be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components can be called by other components or by themselves, and / or invoked in response to detected events or interruptions.Software components configured to run on computing devices can be provided on a computer-readable medium, such as a compact disc, digital video disc, flash drive, magnetic disk, or any other tangible medium, or as a digital download (and may initially be stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code may be stored partially or entirely on a storage device of the executing computing device for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM.It is further understood that hardware components can consist of interconnected logic units, such as gates and flip-flops, and / or can consist of programmable units, such as programmable gate arrays or processors. The computing device 500 can implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, causes or programs the computing device 500 to function as a special-purpose machine. According to one example of the disclosed technology, the techniques described herein are performed by the computing device 500 in response to the hardware processor 502 executing one or more sequences of one or more instructions contained in memory, such as in the machine-readable storage media 504. The execution of the sequences of instructions causes the hardware processor 502 to perform the process steps described herein. In alternative examples, hard-wired circuitry can be used instead of, or in combination with, software instructions. The term "non-transitory media" and similar terms as used here refer to any media that store data and / or instructions that cause a machine to operate in a specific way. Such non-transitory media can include non-volatile and / or volatile media. Non-volatile media include, for example, optical or magnetic disks. Volatile media include dynamic memory. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, a hard disk, a solid-state drive, magnetic tape or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with hole patterns, RAM, PROM and EPROM, FLASH EPROM, NVRAM, any other memory chip or memory cartridge, and networked versions thereof. Non-transitory media differ from transmission media but can be used in conjunction with them. Transmission media are involved in the transfer of information between non-transitory media. For example, transmission media include coaxial cable, copper wire, and fiber optic cable, including the wires that comprise a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communication. The Computing Device 500 can also include a communication interface, such as a network interface, which provides two-way data communication with one or more network connections connected to one or more local area networks (e.g., Network 106). For example, the communication interface can be an ISDN card (ISDN = Integrated Services Digital Network), a cable modem, a satellite modem, or a modem to provide a data communication connection with a corresponding type of telephone line. As another example, the communication interface can be a LAN card (LAN = Local Area Network) to provide a data communication connection with a compatible LAN (or a WAN component to communicate with a WAN). Wireless connections can also be implemented.In such an implementation, the communication interface sends and receives electrical, electromagnetic, or optical signals carrying digital data streams that represent different types of information. A network connection typically provides data communication over one or more networks with other data devices. For example, a network connection might provide a connection over a local area network to a host computer or data equipment operated by an Internet Service Provider (ISP). The ISP, in turn, provides data communication services over the worldwide packet data communication network, now commonly referred to as the "Internet." The signals across the various networks, the signals on the network connection, and the communication interface that carry digital data to and from the computer are exemplary forms of transmission media. The Computing Device 500 can send messages and receive data, including program code, over the network(s), network connection, and communication interface. Using the internet as an example, a server could transmit requested code for an application program over the internet, the ISP, the local network, and the communication interface. The received code can be executed by the 502 hardware processor when received, and / or stored in a memory device or other non-volatile memory for later execution. Each of the processes, procedures, and algorithms described in the preceding sections can be embodied in code components and be fully or partially automated, executed by one or more computing device systems or computer processors comprising computer hardware. These one or more computer systems or processors can also operate to support the execution of the relevant operations in a cloud computing environment or as Software as a Service (SaaS). The processes and algorithms can be partially or fully implemented in application-specific circuits. The various features and processes described above can be used independently or combined in various ways.Various combinations and subcombinations are said to fall within the scope of this disclosure, and certain procedure or process blocks may be omitted in some implementations. The procedures and processes described herein are also not restricted to a particular sequence, and the blocks or states relating thereto may be performed in other appropriate sequences, or may be performed in parallel or in some other manner. Blocks or states may be added to or removed from the disclosed examples. The workload of certain operations or processes may be distributed across computer systems or computer processors, not just within a single machine, but across a number of machines. As used here, a circuit could 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 could be implemented to form a circuit. In implementation, the various circuits described here could be implemented as discrete circuits, or the described functions and features could be shared partially or entirely among one or more circuits.Although various features or elements of functionality may be described or claimed individually as separate circuits, these features and functionality may be shared among one or more common circuits, and such a description is not intended to require or imply that separate circuits are necessary to implement such features or functionality. If a circuit is implemented wholly or partly using software, such software may be implemented to operate with a computing or processing system capable of performing the functionality described therein, such as the Computing Device 500. The above discussion is intended to illustrate the principles and various embodiments of the present disclosure. Numerous variations and modifications will become apparent to the person skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted as encompassing all such variations and modifications. The word "example" is used herein to mean an illustration, case, or demonstration. Any aspect or design described herein as an "example" is not necessarily to be construed as being favored or advantageous over other aspects or designs. Instead, the use of the word "example" is intended to represent concepts in a concrete way. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is to say, unless otherwise specified or clear from the context, "X includes A or B" is intended to mean any of the natural inclusive permutations. That is to say, if X includes A; X includes B; or X includes both A and B, then "X includes A or B" is satisfied in each of the foregoing cases.Furthermore, the articles “a” and “an”, as used in this application and the attached claims, should generally be interpreted as meaning “one or more”, unless otherwise specified or it is clear from the context that they refer to a singular form. In addition, the use of the term “a (article) implementation” or “a (number) implementation” throughout should not imply the same embodiment or implementation unless described as such. QUOTES INCLUDED IN THE DESCRIPTION This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature US 63 / 743,011

[0001]

Claims

A method for performing integrated software development of a software product comprising a plurality of individual software components, wherein the method, using one or more processors, comprises: receiving a notification that a change has been made to a first software component of the plurality of individual software products; in response to the notification, automatically updating an architecture definition associated with the first software component based on the change made to the first software component; updating an architecture of the software product based on the change made to the first software component; compiling the software product; and publishing build artifacts associated with the software product. The method of claim 1, further comprising automatically generating the display in response to the fact that the change is committed to an implementation repository associated with the first software component. The method of claim 1, further comprising autocoding the first software component based on the change. The method according to claim 1, further comprising generating a specification component file for the first software component. The method of claim 4, further comprising determining whether the specification component file has changed and updating the architecture based on the determination of whether the specification component file has changed. The method of claim 1, further comprising: determining whether a change has been made to one of the plurality of individual software components; and, in response to determining that the change has been made to one of the plurality of individual software components, updating an architecture of the software product based on the change made to one of the plurality of individual software components. Method according to claim 1, wherein the software product corresponds to embedded software of a steering system of a vehicle. A system for performing integrated software development of a software product comprising a plurality of individual software components, wherein the system comprises: memory that stores instructions; and one or more processors configured to execute the instructions, wherein the execution of the instructions causes the system to: receive a notification that a change has been made to a first software component of the plurality of individual software products; in response to the notification, automatically update an architecture definition associated with the first software component based on the change made to the first software component; update an architecture of the software product based on the change made to the first software component; compile the software product; and publish build artifacts associated with the software product. System according to claim 8, wherein the execution of the instructions further causes the system to automatically generate the display in response to the fact that the change is committed to an implementation repository associated with the first software component. System according to claim 8, wherein the execution of the instructions further causes the system to autocode the first software component based on the change. System according to claim 8, wherein the execution of the instructions further causes the system to generate a specification component file for the first software component. System according to claim 11, wherein the execution of the instructions further causes the system to determine whether the specification component file has changed and to update the architecture based on the determination of whether the specification component file has changed. System according to claim 8, wherein the execution of the instructions further causes the system to: determine whether a change has been made to one of the plurality of individual software components; and, in response to the determination that the change has been made to one of the plurality of individual software components, to update an architecture of the software product based on the change made to one of the plurality of individual software components. System according to claim 8, wherein the software product corresponds to embedded software of a steering system of a vehicle. A method for performing integrated software development of a software product comprising a plurality of individual software components, wherein the method, using one or more processors, comprises: receiving a notification that a change has been made to an architecture repository associated with the software product; in response to the notification, comparing a current architecture of the software product with a new architecture corresponding to the change made to the architecture repository; based on the comparison, automatically modifying the software product by at least one of: (i) adding a new software component to the software product, (ii) removing an existing component from the software product, and (iii) modifying an existing component of the software product; compiling the software product; and publishing build artifacts associated with the software product. The method of claim 15, wherein the automatic modification of the software product comprises generating at least one of port mappings and task mappings associated with the modification. The method of claim 15, further comprising generating at least one of a C file template and a runtime environment based on the modification. The method of claim 15, wherein adding the new software component includes generating a component specification file for the new software component. The method according to claim 15, further comprising detecting the change made to the architecture repository and automatically generating the display based on the detection of the change. Method according to claim 15, wherein the software product corresponds to embedded software of a steering system of a vehicle.

Images