Software development framework for constructing embedded vehicle controller software

[0002] 1. Field of the Invention

[0003] The present invention relates generally to a computer-implemented software development framework and, more particularly, to a software development system for constructing applications that are to be embedded in one or more microcontrollers residing on a motor vehicle.

[0004] 2. Discussion

[0005] Designing, developing and manufacturing automobiles is an extremely complex process that involves numerous engineering and calibration groups. Similarly, the design and development of embedded controller software for use in an automobile is a complex process that involves numerous engineering groups.

[0006] Typically, the algorithms which serve as the basis for the embedded controller software are developed by one or more engineering groups. During the course of development, numerous vehicle parameters are identified for use in the software. The nomenclature for these vehicle parameters tends to be very descriptive. The software developers then convert the algorithms into source code which serves as the basis for the object code to be embedded into the vehicle's controller. Due to software variable naming constraints provided by the particular programming language, the software variable names found on the source code and object code are not always helpful when trying to identify a vehicle parameter. For the engineers and calibrators who subsequently test, calibrate and implement the object code into the vehicle's controller, there is a need for a mapping between the descriptive vehicle parameter names and the memory location of the parameter in the object code.

[0007] In addition, vehicle parameter information for embedded controller software is typically duplicated in a multitude of files, folders or documents by each of the groups involved with the development process. In some cases, certain vehicle parameter information are not at all documented within the software development environment.

[0008] Therefore, it is desirable to provide a computer-implemented software development system for constructing applications that are to be embedded in one or more microcontrollers residing on a motor vehicle. The software development system should provide a centralized location for vehicle parameter information, eliminate redundancy in vehicle parameter storage, and standardize report formats. The present invention includes a data dictionary that has been designed and implemented to facilitate software development. More specifically, the data dictionary serves as a standard reference tool that contains information about each of the data parameters generated during the software development process. In this way, the data parameters are centralized, without duplication, for use by all of the parties involved with the development and implementation of software.

[0009] In accordance with the present invention, a computer-implemented software development system is provided for constructing applications that are embedded in a microcontroller of a motor vehicle. The development system includes a data dictionary which stores data type information for a plurality of vehicle parameters and is able to generate a parameter definition file having data type information for each vehicle parameter associated with a first application. A calibration repository is used to generate a calibratable file for the first application, where the calibratable file includes calibratable vehicle information and controller executable instructions for the first application. The parameter definition file and the calibratable file are then used by a calibration tool to calibrate the first application in relation to a particular motor vehicle.

[0010] Additional benefits and advantages of the present invention will become apparent to those skilled in the art to which this invention relates from a reading of the subsequent description of the preferred embodiment and the appended claims, taken in conjunction with the accompanying drawings.

[0011] FIG. 1 is a block diagram showing the components of a computer-implemented software development system in accordance with the present invention;

[0012] FIG. 2 illustrates an exemplary condition code table data parameter in accordance with the present invention;

[0013] FIG. 3 illustrates an exemplary fault code array data parameter in accordance with the present invention;

[0014] FIG. 4 is a block diagram showing a memory reporter module of the data dictionary in accordance with the present invention; and

[0015] FIG. 5 is a flowchart showing how an output file is constructed using the memory reporter module of the present invention.

[0016] A computer-implemented software development system 10 for constructing and calibrating applications that may be embedded in one or more microcontrollers of a motor vehicle is depicted in FIG. 1. Although the software development system 10 is presently used to develop and calibrate a single application for use in the engine controller of a motor vehicle, this is not intended as a limitation of the broader aspects of the present invention. On the contrary, the software development system 10 can be used to construct multiple applications which can then be embedded in the engine controller and/or other microcontrollers (e.g., transmission controller) residing on a motor vehicle.

[0017] Prior to entering the calibration stage of the software development process, source code 12 for each application is written, tested and debugged by the software developers. The software developers are confined by the vehicle parameters as defined in a data dictionary 20. Depending on the programming language used to write the source code is 12, the source code 12 is translated into object code 16 by an environment specific compiler 14. The object code 16 is then imported into a calibration repository 40. For purposes of this description, object code 16 refers to machine instructions or machine language that was translated from the source code 12 and can be directly executed by a microcontroller or other central processing unit residing on a motor vehicle.

[0018] A data dictionary, as is well known in the art, is a database that contains “data about the data”. In the software development system 10, the data dictionary 20 provides a central repository for the vehicle parameters used to develop the applications which are embedded into vehicle controllers. As will be more fully explained, the data dictionary 20 provides the implementation details for each vehicle parameter, how to use each vehicle parameter, how to access each vehicle parameter, and the way in which each vehicle parameter is stored in memory.

[0019] As part of the calibration process, the data dictionary 20 also provides a calibration definition file 22 to a calibration repository 40. The calibration definition file 22 contains all of the information needed to define the vehicle calibratable information of an application in the calibration repository 40. The data dictionary 20 is also capable of generating other types of reports and output files, including files that used by various industry standard software development and calibration tools.

[0020] For instance, the data dictionary is operative to generate a parameter definition file 24 having data type information for each parameter defined in an application. The parameter definition file 24 is used by at least some industry standard calibration tools. In a preferred embodiment of the invention, the parameter definition file 24 is an ASAP2 description file. The working group for the standardization of application systems (ASAP) is a European standards body initiated by the German automobile manufacturers. ASAP aims at making the tools and methods generated during the development phase of vehicle electronics compatible with each other and hence interchangeable. An ASAP2 description file is used to describe the internal data of an engine control unit and is typically used as an input to at least some calibration tools. In other words, the ASAP2 description file defines to the calibration tool how the application is configured in memory. The format of the ASAP2 description file is shown in Appendix A.

[0021] The calibration repository 40 is used to maintain vehicle calibratable information encapsulated in the object code 16. For each application, the calibration repository 40 stores its object code and multiple sets of vehicle calibratable information. Since each application may be used in different types of vehicles, multiple sets of vehicle calibratable information are maintained in a database of the calibration repository 40. Each set of vehicle calibratable information may then be associated with a different version of the application, a different vehicle model type, a different vehicle model year, a vehicle model type having different options, or some combination thereof. In this way, the vehicle calibratable information for an application can be optimized for each specific type of vehicle. It is envisioned that different sets of vehicle calibratable information may also be maintained for different calibrators or groups of calibrators.

[0022] In order to facilitate the calibration process, the calibration repository 40 is capable of generating a calibratable file 28 which is used by one of a variety of industry standard calibration tools 30. The calibratable file 28 is comprised of the object code 16 and a corresponding set of calibration values. In this way, the calibration repository 40 provides a means by which calibrators can execute the object code on a controller of a particular vehicle and optimize the vehicle calibratable information for that specific type of vehicle. Although the present invention is not limited to any particular calibration tool 30, the Inca calibration tool as provided by the Etas Company is an exemplary calibration tool. As shown in FIG. 1, the parameter definition file 24 and the calibratable file 28 each serve as an input to the calibration tool 30.

[0023] Lastly, the calibration repository 40 is able to output the production object code 26 that is embedded into the microcontrollers of the production vehicles. To do so, an appropriate set of calibration values is linked to the object code. The object code includes a memory space for the vehicle calibratable information. Each set of calibration values merely mimics the memory space as found in the object code. Therefore, the calibration repository 40 copies a set of calibration values over the memory space in the object code that corresponds to the vehicle calibratable information, thereby generating a production version of the application.

[0024] The data dictionary 20 will now be described in greater detail. In general, the data dictionary 20 stores data type information for a plurality of vehicle parameters. Each vehicle parameter is defined by its own set of attributes. Attributes which are common to all of the parameter types, include: a reference name, a software requirements name, a description, a software requirements identifier, a system identifier, a sub-system identifier, a memory type identifier, and an interface identifier. Each of these attributes are briefly described below.

[0025] The reference name is a field that contains a unique reference name for the vehicle parameter as assigned by the software developers. In contrast, the software requirements name is a field that contains a more descriptive name for the vehicle parameter as provided by the development engineers. Thus, the data dictionary provides a mapping between the reference name and the software requirements name. This mapping allows the development engineers to think in terms of their conceptual variable names while permitting the software developers to work within the software variable naming constraints as provided by the particular programming language. The description field attribute contains a brief description of the vehicle parameter.

[0026] Initially, each vehicle parameter is defined by the development engineers in a software requirements document. The software requirements document outlines the attributes and other characteristics that describe the vehicle parameter as is well known in the art. The software requirements identifier attribute is a standard numerical identifying code associated with the corresponding software requirements document.

[0027] A system identifier and a sub-system identifier are attributes which are used to help identify where the parameter originated in the vehicle. For instance, the system identifier may contain ‘FUEL’ for the fuel system and the subsystem identifier may contain ‘J1850’ for the communication sub-system.

[0028] The memory type identifier is an attribute that contains the type of memory needed for the vehicle parameter within the software development system 10. This attribute may contain, but is not limited to, one of the following valid entries: (a) non-volatile, zero random access memory (RAM) which is for vehicle parameters that need to be initialized to zero and whose value will be retained after power is removed from the microcontroller; (b) non-volatile, initialized RAM which is for vehicle parameters that need to be initialized and whose value will be retained after power is removed from the microcontroller; (c) volatile, zero RAM which is for vehicle parameters that need to be initialized to zero and whose value will not be retained after power is removed from the microcontroller; (d) volatile, initialized RAM which is for vehicle parameters that need to be initialized and whose value will not be retained after power is removed from the microcontroller; (e) calibratable memory which is for the calibratable parameters that can be viewed and altered by the calibrators via the calibrators tool set as well as downloaded into flash memory of the controller; and (f) fixed calibratable memory which is for calibratable parameters that are fixed and thus are not accessible to the calibrators.

[0029] Finally, the interface identifier is an attribute that contains the means by which interaction is achieved between software systems. This field should contain all of pertinent usage information needed by the software developers. In addition to each of these common attributes, each parameter type may have other specific attributes. These other specific attributes may include (but are not limited to) one or more of the following attributes: data type, data size, unit type, predefined valid values, ranges of valid values, equations, etc.

[0030] The data dictionary 20 supports a variety of parameter types, including, but not limited to scalars, two-dimensional tables, three-dimensional tables, registers, condition code tables, and fault code tables. Amongst the conventional parameter types, the scalar parameter is defined as either a scalar or an array. The two-dimensional look-up table is an interpolation table consisting of one independent (input) variable and one dependant (output) variable. Similarly, the two-dimensional look-up table is an interpolation table consisting of two independent (input) variables and one dependent (output) variable. The register parameter is comprised of one or more groups of bits, where each bit or group of bits has a specific meaning.

[0031] At least some of these parameter types are unique to the present invention. For instance, the condition code table is a table that maintains several conditions within the application. The purpose of the condition code table is to provide an indication of when all of the conditions are met or if any one of the conditions are not met. In addition to the common attributes, the condition code table includes the number of X breakpoints which is an attribute that contains the number of conditions in the table. The data structure for an exemplary condition code table is shown in FIG. 2.

[0032] The fault code array is another unique parameter type to the present invention. The fault code array is defined as an array where its values are individual faults that occur within the application software. The purpose of the fault code array is to capture the information necessary to manage each fault. In addition to the common attributes, the fault code array includes a fault identifier which is a pre-assigned service-designated value that is used to aid in diagnosis of the fault, and a pcode identifier which is the J2012 fault code associated with the fault entry. An exemplary data structure for the fault code array is shown in FIG. 3.

[0033] Referring to FIG. 4, the data dictionary 20 further includes a memory reporter module 80 for generating the parameter definition file, calibration file and other output files. In order to generate an output file, an application extraction module 82 first reads a compiler link map 84 that corresponds to an application. As will be apparent to one skilled in the art, a link map provides an association between a software variable name and its location in memory as assigned by the compiler. The application extraction module 82 determines which data objects from the application are defined by the compiler in the link map 84, and then builds a debug command script file 86. The debug command script file 86 is used as an input to a conventional source code debugging tool 90. The debugging tool 90 is subsequently used to further define each of the data objects associated with the application. In addition, the application extraction module 82 builds an execution script file 88 that is used by the source code debugger 90 to determine how to run the command script file 86.

[0034] The memory reporter 80 then initiates the source code debugger 90 which in turn executes the script files 86 and 88. The source code debugger 90 outputs a file containing each data item identified by the source code debugger 90. The application extraction module 82 reformats the output file provided by the source code debugger 90 in order to build an application requirements file 92. As a result, the application requirements file 92 is an array which includes a mangled data name, an unmangled data name and an address for each data item. The application requirements file 92 is sorted by address.

[0035] Next, a report extractor module 94 generates a report requirements file 96. An input report file 98 contains the requirements for the eventual output file 100. Thus, the report extractor reads 94 the input report file 98 and extracts the data items needed to generate the output file 100. The output requirements, including the data items, are sorted and then stored in the reports requirement file 96.

[0036] To generate the output file 100, an report generator module 102 reads each of the application requirements file 92 and the report requirements file 96. By reading, extracting, sorting, and formatting each of the data items contained in these two files 92 and 96, the report generator 102 is able to format the output file 100. FIG. 5 illustrates the methodology associated with memory reporter module 80.

[0037] While the above description constitutes the preferred embodiment of the invention, it will be appreciated that the invention is susceptible to modification, variation, and change without departing from the proper scope or fair meaning of the accompanying claims.