Method and system for parameter profile compiling

INCORPORATION BY REFERENCE

p-0002The following application hereby incorporates by reference each of the following applications filed on an even date herewith, including the application titled “Method and System for Editing Code” by inventors Bulent Kasman and Edmund dela Cruz in its entirety, the application titled “Method and System for Dynamic Patching of Software” by inventor Bulent Kasman in its entirety, and the application titled “Method and System for Dynamic Debugging of Software” by inventor Bulent Kasman in its entirety.

BACKGROUND

p-0003The ability to build, debug, and deploy software programs onto a target device is critical to software development. Debugging often involves monitoring variables, parameters, and/or resources used in a software program. One conventional method of monitoring involves inserting print statements within the program's code and performing a diagnostics session. Monitoring may also be performed during specific times of the program's execution. For example, breakpoints are often used to pause or terminate program execution, allowing the developer perform a diagnostics session in order to view the status of the variables, parameters, and resources at the specified times. However, the conventional debugging methods described above are limited. Since changes to the program code are required during debugging, the program must be recompiled and re-executed in order to view the results of these changes. Thus, the conventional debugging methods cannot be applied to programs that are currently being executed without interrupting the operation of the programs.

p-0004Additional diagnostics interactions with the program code on the target device may also be required, such as downloading patches, extracting data related to program performance and servicing, and/or collecting parameter data relating to a business operating the program. The performance of these interactions may require diagnostics data storage on the target device, thereby limiting the resource of the target device and increasing the overhead required to effectively operate the program code once deployed onto the target device.

SUMMARY OF THE INVENTION

p-0005The present invention relates to a method and system for compiling a parameter profile. According to an embodiment of the present invention, the method comprises extracting context information from an extraction module, where the extracting creates a minimized extraction module, creating a parameter profile from the context information, transmitting the minimized extraction module to a target device, receiving a value extracted from the target device, the value being extracted by the minimized extraction module, and combining the value with at least a portion of the context information in the parameter profile to create a user readable log statement. According to another embodiment of the present invention, the system comprises an extraction element extracting context information from an extraction module, where the extracting creates a minimized extraction module, a creating element creating a parameter profile from the context information, a transmitting element transmitting the minimized extraction module to a target device, a receiving element receiving a value extracted from the target device, the value being extracted by the minimized extraction module, and a combining element combining the value with at least a portion of the context information in the parameter profile to create a user readable log statement. In a further alternative embodiment of the present invention, the system comprises an extraction module configured to extract data from running user code loaded onto a target device, a compiling module configured to compile source code of the extraction module into object code that is transmitted to the target device and extract context information from the extraction module, a parameter profile module including the context information extracted from the extraction module, and a log file created from at least a portion of the context information in the parameter profile module and the data extracted from the running user code.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0006<figref idrefs="DRAWINGS">FIG. 1</figref> shows an exemplary system for generating a parameter profile for capturing information to interpret a diagnostic log according to the present invention.

p-0007<figref idrefs="DRAWINGS">FIG. 2</figref> shows a parameter profile of a compiled sensorpoint code within the exemplary system according to <figref idrefs="DRAWINGS">FIG. 1</figref> of the present invention.

p-0008<figref idrefs="DRAWINGS">FIG. 3</figref> shows an exemplary method for providing an abstracted profile from a sensorpoint for interpreting a diagnostic log generated by the sensor point according to the present invention.

DETAILED DESCRIPTION

p-0009The present invention may be further understood with reference to the following description of exemplary embodiments and the related appended drawings, wherein like elements are provided with the same reference numerals. The present invention is related to systems and methods used to develop, test, and debug software. Specifically, the present invention is related to systems and methods for generating a parameter profile of logging keywords used during a diagnostics session of the software being developed. This parameter profile may be used to interpret log statements, provide context for log statements and correlate log statements to specific locations within the source code. Furthermore, the parameter profile may conserve resources by eliminating overhead on diagnostic tools loaded onto the target device and saving network bandwidth by eliminating the transmission of static or unchanging data to a host device. However, as described in greater detail below, the parameter profile of the present invention is not limited to the development of software, but may also be used to provide context or other information for any type of data that may be extracted from the software and/or the target device.

p-0010Software applications are often created on a host computing device and ported to a target device. This type of development is typical for embedded devices. An embedded device is any device that includes a processor or microcontroller that executes software to carry out desired functions. Normally, an embedded device has fewer resources than a general purpose computer, such as having a slower processor, less memory (cache, RAM, Flash, etc.), etc. Examples of embedded devices include mobile phones, personal digital assistants, smart phones, smart process monitoring devices (e.g., thermostats, pressure sensors, flow sensors, etc.), etc. The exemplary embodiments of the present invention will be described with reference to a diagnostic tool for such embedded devices. However, those skilled in the art will understand that the present invention may be implemented in, for example, a diagnostic tool for software executing on any type of device. As will be described in greater detail below, additional independent program code may be installed onto the target device in order to collect useful diagnostic information during the development of the software application. Embodiments of the present invention will be described with reference to the development of software applications for these target devices in both networked and non-networked environments.

p-0011<figref idrefs="DRAWINGS">FIG. 1</figref> shows an exemplary system <b>100</b> for integrating the editing, compiling and installing of program code within an application according to an exemplary embodiment of the present invention. The system <b>100</b> includes a target device <b>10</b> and a host device <b>20</b>. In one embodiment, both the target <b>10</b> and the host <b>20</b> may be located in a lab environment, while in another embodiment, the target <b>10</b> and/or the host <b>20</b> may be in a field environment. For example, the target <b>10</b> may be deployed in a warehouse, office, etc., while the host resides in a laboratory or central server location. The target <b>10</b> and the host <b>20</b> may include conventional computing components such as a processor (e.g., a microprocessor, an embedded controller, etc.) and a memory (e.g., Random Access Memory, Read-only Memory, a hard disk, etc.). Communication between the target <b>10</b> and the host <b>20</b> occurs over a communication link, which may be a wired (e.g., Ethernet, serial port, Universal Serial Bus, etc.) or wireless (e.g., Bluetooth, IEEE 802.1x, etc.) connection.

p-0012The host <b>20</b> may include a user interface <b>22</b>, a database <b>24</b> and workbench software <b>26</b>. The user interface <b>22</b> enables a user (e.g., a software developer) to interact with the host <b>20</b> by receiving instructions and data requests. The user interface <b>22</b> may comprise any number of standard input and/or output devices, such as a keyboard, a mouse, a display, etc. Through the user interface <b>22</b>, the developer may instruct the host <b>20</b> to transmit data to and/or from the target <b>10</b>. The data may include sensorpoint modules and monitoring data. As will be discussed in detail below, sensorpoint modules comprise program code that the developer can implement on the target <b>10</b>. Monitoring data may include any relevant data that the developer wishes to receive from the target <b>10</b>, such as device information, alarms and error messages, log information, and audit information (e.g., information related to users modifying devices and/or sensorpoint modules). The monitoring data may also relate to device type. For example, if the target <b>10</b> is a cell phone, the monitoring data may include call usage information, signal strength information, etc. The monitoring data may be transmitted automatically (e.g., a predetermined intervals) or upon request by the developer. For example, the user may request to view a log file generated by the target <b>10</b> in order to view specific program output.

p-0013The workbench software <b>26</b> is a software development tool used by the developer to create, modify, and debug software programs. The workbench software <b>26</b> may comprise a software suite that includes any number of individual software development programs, such as a compiler, a debugger, a source code analyzer, a text editor, etc. These individual programs may either be run independently of a running application or within a main development program. Using the workbench software <b>26</b>, the user can create a sensorpoint module, write and edit code for the sensorpoint module, compile the code, abstract a parameter profile from the compiled code, and save the sensorpoint module to the database <b>24</b> or as a local file system. Once the sensorpoint module is saved, it may be selected for transmission to the target <b>10</b>. Those skilled in the art will understand that the sensorpoint code as written may not be the same as the actual code executed by the target <b>10</b>. For example, the actual code may be an executable binary file created as a result of compiling and linking the sensorpoint code. The binary may be included in the sensorpoint module as an object file. In addition, the sensorpoint module may include multiple files, such as source, header and library files. These files may be installed individually or together with the entire sensorpoint module.

p-0014The database <b>24</b>, or local file system, stores sensorpoint modules, monitoring data (e.g., diagnostics logging data), and other types of data specified by the developer. The database <b>24</b> may also include user information, customer information, information regarding the target <b>10</b> (e.g., device type), parameter information regarding a business process, etc. The database <b>24</b> may be organized in any number of ways, including separate data structures for holding information corresponding to a specific target, a specific data type (e.g., sensorpoint modules), etc. The database <b>24</b> also allows for sensorpoint modules to be grouped together according to the specifications of the developer. For example, the developer may wish to group subcomponents of a larger program together. The database <b>24</b> is located on a writable memory, and may be accessed via the user interface <b>22</b>.

p-0015The target <b>10</b> may further include a Device Software Management (DSM) agent <b>12</b> that may communicate with the host <b>20</b>, specifically, for example, with the workbench software via the communication link. The DSM agent <b>12</b> coordinates the sending and receiving of data. Instructions and data requests are received by the DSM agent <b>12</b> and processed accordingly. When data is transmitted or received, the DSM agent <b>12</b> may first place the data into a buffer. For example, received sensorpoint modules may be temporarily stored in a buffer before writing to the memory of the target <b>10</b>. Likewise, data transmitted to the host <b>20</b> may first be placed in a buffer and sent when the data is ready for transmission and/or the host <b>20</b> is ready to receive the data. The DSM agent <b>12</b> may be implemented in hardware, software, or a combination thereof.

p-0016The target <b>10</b> operates using a user code <b>14</b>, which comprises a program running in an operating system or a stand-alone program. The user code <b>14</b> may be written in any programming language (e.g., C/C++, Java, Assembly language, etc.). The user code <b>14</b> may be any program that the developer wishes to run on the target <b>10</b>. For example, the user code <b>14</b> may be a main program or subroutine being developed for implementation on the target <b>10</b>. The user code <b>14</b> may include source, header, library, object, and other data files.

p-0017The target <b>10</b> may also include sensorpoint object code <b>15</b>. Similar to the user code <b>14</b>, the sensorpoint object code <b>15</b> may include source, header, library and object files. According to the embodiments of the present invention described herein, a sensor point is defined as a piece of code that is compiled independently of a running application (e.g., the compiled user code <b>14</b>). The sensorpoint object code <b>15</b> may be executed by the running application via branch instructions inserted into the running application (e.g., the executable binary). The sensorpoint object code <b>15</b> may include keywords for logging purposes, wherein the keywords may correspond to both sensorpoint directives (e.g., sensorpoint thread) and instrumentation points identifying the locations of the user code <b>14</b>. The use of the keywords for the generation of parameter profiles will be described in detail below.

p-0018The target <b>10</b> may also include an event handler <b>16</b>, a trace handler <b>17</b>, a log handler <b>18</b> and a core dump <b>19</b>. The event handler <b>16</b> responds to events encountered during execution of the user code <b>14</b>. The events may be user-created (e.g., a mouse click, a menu selection, etc.) or program generated (e.g., a program exception, a software interrupt, etc.). The trace handler <b>17</b> stores trace information specified by the user code <b>14</b>. For example, the trace information may include all read and write instructions, along with corresponding data values and variable names. The trace handler <b>17</b> works in conjunction with the log handler <b>18</b> to store the trace information into one or more log files, which may then be outputted (e.g., displayed at the target <b>10</b> or transmitted to the host <b>20</b>) for viewing. Using the log handler <b>18</b>, the developer can specify where log files and what types of information (e.g., reads/writes, error messages, diagnostics data, etc.) should be stored. The core dump <b>19</b> handles program crashes by providing a log for specific memory contents, which can be viewed after the program crashes.

p-0019Those skilled in the art will understand that the system <b>100</b> and the various components described for the host <b>20</b> and the target <b>10</b> are only exemplary and are being used to illustrate an exemplary embodiment of a parameter profile according to the present invention. However, the parameter profile of the present invention may be implemented on systems that do not include the components described herein, e.g., sensorpoints. Those skilled in the art will understand that the functionality described for the parameter profile may be implemented on other systems that include other components. Specifically, the functionality described for the sensorpoints, e.g., the extraction of data from the user code <b>14</b> and/or target <b>10</b>, may be performed by another component. Such a component may have the same characteristics as a sensorpoint (e.g., compiled code that is executed without interrupting the execution of the user code <b>14</b>) or it may have different characteristics. Thus, the functionality of concern is the ability to extract data from the user code <b>14</b> and/or target <b>10</b>. Accordingly the term “extraction module” will be used to refer to any component that may perform the extraction of data as described herein.

p-0020<figref idrefs="DRAWINGS">FIG. 2</figref> shows a parameter profile <b>200</b> of a sensorpoint source code <b>215</b> within the exemplary system <b>100</b> according to <figref idrefs="DRAWINGS">FIG. 1</figref> of the present invention. The parameter profile <b>200</b> may include keywords <b>225</b> abstracted from the sensorpoint code <b>15</b> such as logging information, wherein the logging information may reference the user code <b>14</b>, a user file name, a line number within a file, location context information, a log identifier, and a log status. Thus, the keywords <b>225</b> included within the parameter profile <b>200</b> may be used to interpret a diagnostics log generated by the target <b>10</b>. The use of a parameter profile <b>200</b> within the exemplary system <b>100</b> may eliminate the need to use the memory of the target <b>10</b> to store information required to interpret logs and logs status. The only logging information that is needed from the target <b>10</b> is the log identifier(s) from a log data entry generated by, for example, the sensorpoint object code <b>15</b> of the target <b>10</b>. Therefore, the combination of the log identifier generated at the target <b>10</b> with the parameter profile <b>200</b> may create one or more complete log statements.

p-0021An exemplary sensorpoint source code <b>215</b> may be written in the C programming language, compiled and linked on the host <b>20</b>, saved as a sensorpoint object code <b>15</b>, and transmitted to the target <b>10</b> for execution. Branch instructions are inserted into a specific location(s) (i.e., the instrumentation points) of the user code <b>14</b> as desired by the developer, and may also be transmitted from the host <b>20</b> as part of the sensorpoint module. In other embodiments, the sensorpoint source code <b>215</b> may be written and the instrumentation points specified through a user interface located on the target <b>10</b> itself. The branch instructions may be inserted by patching the running user code <b>14</b> with precompiled branch instructions pointing to the sensorpoint object code <b>15</b>. When the application reaches the instrumentation point(s), the sensorpoint object code <b>15</b> is run before execution of the user code <b>14</b> resumes. Thus, the developer may debug, develop and monitor the user code <b>14</b> without having to recompile or interrupt the execution of the user program.

p-0022As described above, the sensorpoint source code <b>215</b> may include multiple files, such as source, header and library files, wherein these files may be compiled and installed individually or together with the sensorpoint source code <b>215</b>. Included within these files may be an original sensorpoint file (e.g., a “.spc” file) that contains keywords <b>225</b> for logging purposes. These keywords <b>225</b> may contain the unchanging (or constant) portions of a log statement, such as user source code <b>14</b> insertion location and context information. In addition, one or more log statements may be contained within a logging file that is viewable to a user for diagnostic and troubleshooting purposes. For example, the log data entries of a logging file may be data for an error log that records events such as sensorpoint module installation failures, sensorpoint module compilation errors, device execution errors, and other various types of error events. One or more of the sensorpoint modules of the target <b>10</b> may be utilized for the generation of the logging information file. As described above, the sensorpoint object code <b>15</b> is a software component that includes the compiled sensorpoint source code <b>215</b> and instructions relating to how the compiled sensorpoint source code <b>215</b> should be implemented.

p-0023Those skilled in the art will understand that the log statements are not limited to errors, but may include any information that may be extracted from the user code <b>14</b> and/or target <b>10</b>. for example, the sensorpoint object code <b>15</b> may simply include instructions to read the value of a particular register at a certain point in the code. This information may be valuable to the developer for monitoring or diagnostic purposes. Those skilled in the art will understand that the data that may be extracted using sensorpoints (or similar construct) from the target <b>10</b> while user code <b>14</b> is executing is only limited by the amount of data that is included in the target <b>10</b>.

p-0024In order to generate the parameter profile <b>200</b>, keywords <b>225</b> may be selected during a compilation process. Seeing as the workbench software <b>26</b> may be used for writing, editing, compiling, and saving the sensorpoint source code <b>215</b>, a sensorpoint compiler <b>210</b> may be included within the workbench software <b>26</b> for compiling sensorpoint source code <b>215</b> written for the sensorpoint source module. Once one or more sensorpoint modules are developed, the sensorpoint compiler <b>210</b> may be activated to compile all or some of the sensorpoint source code <b>215</b>. During the compilation process, the sensorpoint compiler <b>210</b> may compile the sensorpoint source code <b>215</b>, thereby creating the sensorpoint module including sensorpoint object code <b>15</b> (e.g., a “.usm” file).

p-0025In addition, the sensorpoint compiler <b>210</b> may extract the keywords <b>225</b> from the sensorpoint source code <b>215</b> or the sensorpoint object code <b>15</b>. The sensorpoint compiler <b>210</b> may also extracts relevant file information about the application source and binary files as keywords <b>225</b>. Using the extracted keywords <b>225</b>, the sensorpoint compiler <b>210</b> may generate a parameter profile <b>200</b>. The parameter profile <b>200</b> may be, for example, an additional file in extensible markup language (“XML”) that captures the keywords <b>225</b> information from the user source code <b>14</b>. Thus, the parameter profile <b>200</b> may be an abstract file that includes some or all of the static information of the sensorpoint source code <b>205</b>. This parameter profile <b>200</b> may then be used to interpret log data entries that are generated by the sensorpoint module of the target <b>10</b>. Thus, the use of the parameter profile <b>200</b> according to embodiments of the present invention may greatly decrease the amount of information needed in the sensorpoint object code <b>15</b> that is stored in the memory of the target <b>10</b> since some or all of the information needed to interpret log statements and log status remains stored on the host <b>20</b> in the parameter profile <b>200</b>. The target <b>10</b> may only need to store a log identifier <b>250</b> from the log data entry and communicate the log identifier <b>250</b> to the host <b>20</b> over the DSM agent <b>12</b>. As described above, the DSM agent <b>12</b> may coordinate the sending and receiving of data between the host <b>20</b> and the target <b>10</b> via a communication link.

p-0026Upon receiving the log identifier <b>250</b>, the host <b>10</b> may combine the log identifier <b>250</b> with the parameter profile <b>200</b> in order to supply any of the constant, unchanging portions of logging information that are necessary to generate a complete log statement. Furthermore, the combined information from the log identifier <b>250</b> and the parameter profile <b>200</b> may be displayed to the user via the user interface <b>22</b>.

p-0027In an exemplary application of the present invention, the parameter profile <b>200</b> may be helpful during a diagnostics session, which involves analyzing the log identifiers generated by a target <b>10</b> as it executes an application. The parameter profile <b>200</b> may provide contextual data about each of the log identifiers, thereby allowing for the log identifier and the context data to be displayed to the user at the same time. Therefore, embodiments of the present invention may correlate the data within the log with the user source code <b>14</b> and identify the location within the user source code <b>14</b>. Correlating the information allows for a quicker decision to be made about the behavior of the system <b>100</b> based on the context and provides a more efficient software development environment.

p-0028For example, the sensorpoint object code <b>15</b> may determine one log data entry of “0xef5643” within a large file of log identifiers. However, without the actual log statement that produced the log identifier being instantly available to the user during the diagnostics session, the log data entry becomes meaningless. One possible solution may be to have the target <b>10</b> store and list the user source code <b>14</b> context information as a part of the log data entry within the file, such as “malloc( ) function returned: 0xef5643.” It is clear to see that this solution greatly increases the amount of memory and other resources needed, both within the target <b>10</b> as well as by a networked environment, in order to store and transmit the additional context information.

p-0029In contrast, according to the exemplary embodiments of the present invention, the context information may be stored in the parameter profile <b>200</b> that remains on the host <b>20</b>. As opposed to having the additional information stored and transmitted to/from the target <b>10</b>, the sensorpoint object code <b>15</b> that extracts the log identifier may be limited to simply the information needed to extract the log identifier without extracting context information. Thus, the sensorpoint object code <b>15</b> that is transmitted over the network and stored on the target <b>10</b> required less resource. In addition, the log files (including log identifier <b>250</b>) that are stored on the target <b>10</b> and transmitted back to the host <b>20</b> also require less resources. As described above, the log identifier may then be combined with the parameter profile <b>200</b> to provide any necessary information to interpret the log identifier. By storing the constant, unchanging portions of the log statement with location context information within the parameter profile <b>200</b>, the present invention may reduce the overhead associated with the logging framework.

p-0030Those skilled in the art will understand that while the exemplary embodiment has been described with reference to a logging operation, the present invention is not limited to logging operations. As described above, sensorpoint may be used to extract any type of data from the user code <b>14</b> and/or target <b>10</b>. The parameter profile may be used to provide content information for any of this extracted data. For example, if the target <b>10</b> is an embedded automotive component that includes the monitoring of oil pressure, a deployed sensorpoint may extract the oil pressure value from the target <b>10</b> (e.g., a value of 150). However, by combining this value with the context information in the parameter profile (e.g., “The current oil pressure is <value>”.), the developer or any other interested person (e.g., maintenance technician) may quickly and easily understand the data extracted from the target <b>10</b>. Thus, this example shows that the parameter profile <b>200</b> is not limited to the traditional limited definition of logging related to software debugging and testing, but may be used for a broader expanded logging which includes the extraction of any data from the user code <b>14</b> and/or target <b>10</b>.

p-0031<figref idrefs="DRAWINGS">FIG. 3</figref> shows an exemplary method <b>300</b> for software development and parameter profile <b>200</b> development according to the present invention. Beginning with step <b>310</b>, a sensorpoint module is created using the workbench software <b>26</b>. As previously discussed, the sensorpoint module is a software component that includes the compiled sensorpoint source code <b>215</b> and instructions relating to how the compiled sensorpoint source code <b>215</b> should be implemented. Furthermore, the sensorpoint source code <b>215</b> may contain one or keywords <b>225</b> within the code for logging purposes. These keywords <b>225</b> may relate to information from the user code <b>14</b> that is used to interpret one or more log statements generated by the target <b>10</b>. The workbench software <b>26</b> may be accessed using the user interface <b>22</b>, or from the target <b>10</b> if the target <b>10</b> has its own user interface. If the sensorpoint module is a newly created module, the sensorpoint code is written, packaged within the module and stored in the database <b>24</b>. Alternatively, if the sensorpoint module already exists, the existing sensorpoint code is modified and saved. The developer then specifies the user code <b>14</b> location(s) in which the branch instruction(s) should be placed.

p-0032In step <b>312</b>, the sensorpoint source code <b>215</b> is compiled using the sensorpoint compiler <b>210</b> of the workbench software <b>26</b> and saved in the database <b>24</b>. The compiled sensorpoint source code <b>215</b> is then linked. That is, the individual files (source, header, library, etc.) that comprise the compiled sensorpoint source code <b>215</b> are combined into a single executable file (i.e., the executable binary). For example, if the programming language is C, the individual files may be placed into a User Sensorpoint Module (USM) file.

p-0033In step <b>314</b>, the sensorpoint compiler <b>210</b> abstracts at least one of the keywords <b>225</b> from the compiled sensorpoint source code <b>215</b>. As described above, abstracting the keywords <b>225</b> may eliminate the need to use additional memory on the target <b>10</b> once the sensorpoint module is installed onto the target <b>10</b>. Since the information within the keywords <b>225</b> relates to the unchanging portions of the logging statements, namely the user code <b>14</b> and location context information, the target <b>10</b> may avoid storing the information and limit storage primarily to the log identifiers generated by the target <b>10</b>.

p-0034In step <b>316</b>, the sensorpoint compiler <b>210</b> may use the keywords <b>225</b> in the generation of the parameter profile <b>200</b>. Therefore, the parameter profile <b>200</b> may provide an abstracted profile from the sensorpoint module that may include all of the contextual information from the user source code <b>14</b>. Thus, the parameter profile <b>200</b> may be composed of detailed information that would be needed to interpret the log statements generated by the target <b>10</b>. It should be noted that the sensorpoint compiler <b>210</b> may generate the parameter profile <b>200</b> in the form of an XML file.

p-0035In step <b>318</b>, the compiled sensorpoint source code <b>215</b> is installed by transmitting the compiled sensorpoint source code <b>215</b> as sensorpoint object code <b>15</b> from the host <b>20</b> to the target <b>10</b>. The DSM agent <b>12</b> receives the sensorpoint object code <b>15</b>, saves it into memory allocated to the sensorpoint object code <b>15</b>, processes the executable binary and updates the user code <b>14</b> with the branch instructions. During this time, the target <b>10</b> continues to execute the user code <b>14</b> and does not encounter any interruption during running of the user source code <b>14</b>. If the user code <b>14</b> encounters the branch instructions during execution, program execution is temporarily suspended in order to allow the sensorpoint program to execute.

p-0036In step <b>320</b>, a diagnostics session may be performed wherein the workbench software <b>26</b> of the host <b>20</b> receives log information generated by the target <b>10</b>. The log information may include a plurality of log identifiers which pertaining target-specific information such as data related to the operation of the installed software and physical parameter data related to the business processes. For example, the physical parameter data may be the oil pressure on a motorized vehicle, the battery level on a mobile computing device, etc.

p-0037Once the host <b>20</b> receives the log information, the log identifiers may be combined with the parameter profile <b>200</b> in order to correlate the log identifiers with the user source code <b>14</b> and the location in the user source code <b>14</b>. The user may view the combined information via the user interface <b>22</b>. By having each log identifier displayed at the same time and place as the user source code <b>14</b> context information, the user may efficiently assess both the operation of the software and the parameters of the business processes in order to quickly make decisions regarding the behavior of the system based on the context information. As described above, the log information provides access to log file data that may be viewed by the user for diagnostic and troubleshooting purposes. For example, the log file data may be an error log that records error events such as sensorpoint module installation failures, device execution errors, sensorpoint module compilation errors and other types of error events. Thus, the user may determine whether results of the user program are as expected and, if necessary, makes changes to the sensorpoint object code <b>15</b> by repeating steps <b>310</b>-<b>318</b>.

p-0038It is important to note that within the parameter profile <b>200</b>, each of the log statements may be assigned a name. In addition, within the target <b>10</b>, a name to an identifier table may be created and transmitted to the host <b>20</b>. The transmission of the identifier table may be performed once for all of the log statements. The remainder of the log entries from device may be referred to the log id and values. Once the log statement is mapped to a log name in the host <b>20</b>, the log name may provide information about the log values, such as, for example, the number of parameters logged for each log statement, the parameter data types, the constant data values, etc.

p-0039It will be apparent to those skilled in the art that various modifications may be made in the present invention, without departing from the spirit or the scope of the invention. Thus, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claimed and their equivalents.