US20030061292A1 - System and method for providing an interface for com-compliant applications to communicate with embedded systems - Google Patents

System and method for providing an interface for com-compliant applications to communicate with embedded systems Download PDF

Info

Publication number
US20030061292A1
US20030061292A1 US10/105,062 US10506202A US2003061292A1 US 20030061292 A1 US20030061292 A1 US 20030061292A1 US 10506202 A US10506202 A US 10506202A US 2003061292 A1 US2003061292 A1 US 2003061292A1
Authority
US
United States
Prior art keywords
communication
interface
com
thread
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/105,062
Inventor
Mark Underseth
Kirk Fertitta
Hugues Valois
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
S2 TECHNOLOGIES Inc
Original Assignee
S2 TECHNOLOGIES Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by S2 TECHNOLOGIES Inc filed Critical S2 TECHNOLOGIES Inc
Priority to US10/105,062 priority Critical patent/US20030061292A1/en
Assigned to S2 TECHNOLOGIES, INC. reassignment S2 TECHNOLOGIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FERTITTA, KIRK, UNDERSETH, MARK, VALOIS, HUGUES
Publication of US20030061292A1 publication Critical patent/US20030061292A1/en
Priority to US11/061,283 priority patent/US7530076B2/en
Priority to US11/768,853 priority patent/US20080016498A1/en
Priority to US12/435,998 priority patent/US20090217292A1/en
Priority to US12/985,242 priority patent/US20110107348A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software reuse
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/542Intercept
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/546Xcast
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/547Messaging middleware
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure
    • Y10S707/99945Object-oriented database structure processing

Definitions

  • the field of the invention relates to development and testing. More particularly, the field of the invention relates to the development and testing of software.
  • An embedded device typically includes a microprocessor and application software.
  • the application software runs under the control of a real-time operating system (RTOS) and is typically partitioned into one or more threads.
  • a thread is an independent unit of executable software that shares the control of the microprocessor with other defined threads within the embedded system.
  • a thread is allocated its own stack space, given a “priority”, and assigned other resources that enable the thread to run as an “independent” entity.
  • Stack space is a section of memory reserved for temporary storage of local variables. Priorities are used by the RTOS to determine which thread gets control of the microprocessor if more than one thread is waiting.
  • Resources can include miscellaneous items such as queues, flags, etc., that are required by the RTOS to manage a thread.
  • Other common terms used for a thread are “task” and “process.”
  • a process also implies a separate address space which protects different processes from adversely affecting each other.
  • An example of a process running on a desktop computer using Microsoft's Windows Operating System (OS) is Microsoft Word.
  • a common method for threads to communicate with each other is via a messaging application programming interface (API) that is provided by the operating system.
  • a message typically includes an event and optionally a block of data that is sent between at least two threads.
  • a thread (“the sender”) builds a message and invokes a specific API from the RTOS.
  • the RTOS notifies the other thread (“the receiver”) that some type of event has occurred.
  • the receiving thread then reads the incoming message.
  • Another common method for threads to communicate is via a function call. Using a function call provided by one thread can be invoked by another thread. Likewise functions can be called by other functions that co-exist in the same thread.
  • Other common terms for a function include a subroutine, a procedure, or a method.
  • the term “communication interface” is intended to embrace any interface for communicating data between two threads, such as via either messaging or remote function call communication.
  • known testing systems require the use of the embedded device that has an operational RTOS to test the communication interfaces of the threads and to test the execution of the threads themselves.
  • known systems do not have the ability to simulate communication interfaces and the corresponding threads that support them.
  • interface definition files define the format of the messages expected by the embedded software.
  • Languages such as Visual Basic, LabVIEW, etc., cannot use standard C interface definition files that define the format of the interfaces. Thus, software engineers that use these languages cannot test the threads executing on the embedded device.
  • One aspect of the invention comprises a system for providing communication between a host computer and an embedded computer.
  • the system comprises an embedded computer executing a plurality of threads that provide a plurality of communication interfaces, each communication interface having a plurality of data fields and a communication database identifying each of the communication interfaces.
  • the communication database is automatically generated, at least in part, from information comprising: an interface description file that defines the communications interfaces; machine characteristics of the embedded device; and machine characteristics of a host platform.
  • the system also comprises a communication module for providing an application programming interface for a COM-compliant application to access the communication interface. The communication module is automatically generated based upon information from the communication database.
  • An object in the COM-compliant application identifies at least one of the communication interfaces in the communication database and invokes a function with respect to at least one data field in the identified communication interface via the application programming interface.
  • the function is selected from the group comprising: storing data in one of the data fields, reading data from one of the data fields, and testing a data field.
  • Another aspect of the invention comprises a system for providing communication between a host computer and an embedded computer.
  • the system comprises: an embedded computer executing a plurality of threads that each provide a communication interface; a communication database identifying the communication interface of each of the threads; and a COM object configured to provide a plurality of functions to a COM-compliant application for a communicating with each of the communication interfaces, wherein the COM object is automatically generated based, at least in part, upon the communication interfaces in the messaging database.
  • Another aspect of the invention comprises a method of providing access to a communication, the method comprising: providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and accessing the communication interface via the COM-compliant application.
  • Yet another aspect of the invention comprises a system for providing access to a communication.
  • the system comprises: means for providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and means for accessing the communication interface via the COM-compliant application.
  • Yet another aspect of the invention comprises a system for providing a communication interface that is accessible by a plurality of components, the system comprises: a COM-compliant object; at least one thread executing on an embedded computer; and at least one communication module which is configured to provide an application programming interface for the COM-compliant object to communicate with the thread.
  • FIG. 1 is a block diagram illustrating a development and testing system for testing an embedded computer.
  • FIG. 2 is a block diagram illustrating certain components of a communication database that is part of the development and testing system of FIG. 1.
  • FIG. 3 is a block diagram illustrating another embodiment of the development and testing system of FIG. 1.
  • FIGS. 4A and 4B are a diagram of an exemplary script that can be used to communicate with the embedded computer of FIG. 3.
  • FIG. 5 is a block diagram illustrating another embodiment of the development and testing system of FIG. 1.
  • FIG. 6 is a block diagram illustrating the exemplary contents of the communication database of FIG. 1.
  • FIG. 7 is a block diagram illustrating an exemplary object hierarchy of the generated component of FIG. 5.
  • FIG. 8 is a flowchart illustrating a process of modifying a source file for use with the development and testing system of FIG. 1.
  • FIG. 9 is a flowchart illustrating a process of building the communication database of FIG. 1.
  • FIG. 10 is a flowchart illustrating a process of using the host platform communication module of FIG. 1.
  • FIG. 11 is a flowchart illustrating a process of formatting a communication.
  • FIGS. 12 A- 12 D illustrate exemplary methods of managing pointer data when transmitting the pointer data between two platforms having different machine characteristics.
  • FIG. 13 is a flowchart illustrating a process of using a scripting file to communicate with threads executing on the embedded computer.
  • FIG. 14 is a flowchart illustrating a process of loading the messaging automation component of FIG. 3.
  • FIG. 15 is a flowchart illustrating a process of registering a thread executing in a script with the development and testing system of FIG. 3.
  • FIG. 16A is a flowchart illustrating a process of sending a message communication from a script to the development and testing system of FIG. 3.
  • FIG. 16B is a flowchart illustrating a process of sending a invoking a function call from a script to the development and testing system of FIG. 3.
  • FIG. 17A is a flowchart illustrating a process of a script receiving a message via a script from the development and testing system of FIG. 3.
  • FIG. 17B is a flowchart illustrating a process of a script receiving a communication via remote function call from the development and testing system of FIG. 3.
  • FIG. 18 is a flowchart illustrating a process of utilizing the generated component of FIG. 5.
  • FIG. 19 is a flowchart illustrating a process of launching the COM composer of FIG. 5.
  • FIG. 20 is a flowchart illustrating a process of building the generated component of FIG. 5.
  • FIG. 21 is a flowchart illustrating a process of generating an interface of the generated component of FIG. 1.
  • FIG. 22 is a flowchart illustrating a process of using the generated component of FIG. 5 from any COM-compliant language.
  • FIG. 23 is a flowchart illustrating a process of testing one of the communication interfaces that is identified by the communication database of FIG. 1.
  • FIG. 24 is a flowchart illustrating a process of generating data sets of information based upon monitoring communications that are transmitted between at least two
  • FIG. 25 is an exemplary user interface for testing messages.
  • FIG. 26 is an exemplary user interface for testing remote function calls.
  • FIG. 27 is a flowchart illustrating a process of generating template code for use with the development and testing system of FIG. 1.
  • FIG. 28 is a flowchart illustrating a process of generating code for handling a message that is defined by a predefined communication interface.
  • FIG. 29 is a flowchart illustrating a process of generating message handling code.
  • FIG. 30 is a flowchart illustrating a process of generating code to send a message to a predefined communication interface.
  • FIG. 31 is a flowchart illustrating a process of generating code for handling inter-platform messaging in response to a function call.
  • FIG. 32 is a block diagram illustrating exemplary generated code.
  • FIG. 33 is a block diagram illustrating exemplary generated code.
  • FIG. 1 is a block diagram illustrating one embodiment of a DAT system 100 .
  • the development and testing (“DAT”) system 100 allows developers to have automatic and seamless access to their defined communication interfaces.
  • the DAT system 100 enables threads to run on distributed platforms, and allows any programming language seamless access to the interfaces.
  • the DAT system 100 comprises an embedded computer 104 that is in data communication with a host computer 108 .
  • the embedded computer 104 executes an embedded computer communication module 112 that is used to route communications to threads 114 executing on the embedded computer 104 .
  • the host computer 108 executes a host computer communication module 116 that is used to route messages to threads 120 executing on the host computer 108 .
  • the embedded computer communication module 112 and the host computer communication module 116 are able to route to each other messages and/or other communications sent via other interfaces originating from one platform that are destined for transmission to the other platform. In one embodiment of the invention, all communications from one platform to the other platform are transmitted via the embedded computer communication module 112 and the host computer communication module 116 .
  • the embedded computer 104 can reside on a telephone, a card on a peripheral device, an automobile, a refrigerator, or any other electronic device.
  • the host computer 108 can include any computing device that includes a display and an input device, e.g., mouse, keyboard.
  • the host computer 116 also comprises a communication database 124 that automatically compiles the embedded and host's interface definition files to capture the “characteristics” of a communication interface.
  • the DAT system 100 provides a standardized API for messaging and tracing, contains a protocol suite used to implement a seamless messaging and tracing environment, and implements the communication link between the two platforms.
  • the API that is provided by the DAT system 100 includes interfaces for the following: (i) registering a message; (ii) reading a message; (iii) sending command data; (iv) sending response data; (v) broadcasting a message; (vi) subscribing to a message; (vii) returning the list of messages stored in the communication database; (viii) returning the message format of a specific message; and (ix) returning the name and/or identifier of a specific message. Further exemplary API of the DAT system 100 are described below.
  • a studio module 128 provides a graphical user interface and testing environment for testing the communication interfaces that are identified by the communication database 124 .
  • the DAT system 100 provides complete visibility and control of all the messages and remote function calls defined by an embedded software application.
  • a developer can scan the entire list of messages and/or remote function calls within the database and display them on a screen. Once a specific message or remote function call is selected, the communication database 124 can be queried to return the element types and names associated with the message.
  • each of the threads in the embedded computer 104 and the host computer 108 register with the DAT system 100 .
  • Registration enables the DAT system 100 to dynamically route messages without having to “hardcode” a routing table.
  • Threads at anytime can call a specific application programming interface “API” that is offered by the DAT system 100 to inform the DAT system 100 that the requesting thread “owns” a selected message. Owns, in this context, means that the specific thread receives the message anytime another thread and or application sends it.
  • the DAT system 100 determines whether the owning thread is local or on the other platform. If the platform is local, the message is directly routed to the owning thread.
  • the message is directly routed to the other platform. If the message originates at the embedded computer 104 , upon receipt, the host computer 108 formats the message to be compatible with the machine characteristics of the host computer 108 . If the message originates at the host computer 108 , the host computer 108 formats the messages to be compatible with the machine characteristics of the embedded computer 104 .
  • the embedded computer communication module 112 , the host computer communication module 116 , and the studio module 128 each comprise various sub-routines, procedures, definitional statements, and macros.
  • the computer communication module 112 , the host computer communication module 116 , and the studio module 128 may be written in any programming language such as C, C++, BASIC, Java, Pascal, and Fortran and may be run under the well-known operating system.
  • C, C++, BASIC, Pascal, Java, and Fortran are industry standard programming languages for which many commercial compilers can be used to create executable code.
  • the embedded computer 104 may execute under the control of any off-the-shelf or proprietary real-time operating system such as: VxWorks, Nucleus, ThreadX, Windows CE, RTXC, and Embedded Linux.
  • the host computer 108 may execute under the control of any off-the-shelf or proprietary operating system, such as: UNIX, LINUX, Disk Operating System (DOS), OS/2, PalmOS, VxWorks, Windows 3.X, Windows 95, Windows 98, Windows NT, Windows CE, and Windows XP.
  • Each of the threads on embedded computer 104 and the host computer 108 can communication respectively with the embedded computer communication module 112 and the host computer communication module 116 via a predefined application programming interface API. Set forth below are described certain routines provided by the API. It is to be appreciated that other routines may also be provided.
  • Un-register Un-register the object as a spy ⁇ Dataset methods> Defined below Owner Functions API Methods Register Registers ownership of the service associated with the function Read Parameter List Reads the Parameter List sent by the Caller Return Sends the Return Value to the Caller (User). Un-register Un-registers ownership of the function. ⁇ Dataset methods> Defined below User Function API Methods Call Calls the remote function with the Object's Parameter List Read Return Value Reads the Return Value returned by the Owner.
  • Spy Function API Methods Read Parameter List Reads (spies on) a copy of the Parameter List sent by the Caller Read Response Reads (spies on) a copy of the Response sent from the Owner to the User Register Register the Object as spy of the interface to thereafter receive copies of all Calls and Returns made between users and owners of the function. Un-register Un-register the object as a spy.
  • Dataset methods Defined below Datasets Methods Clear All Datasets Clears/Deletes all datasets associated with either the Command or Response (Messages), or Input or Output (Functions) Delete Datasets Deletes a specified number of datasets Insert Datasets Inserts a specified number of datasets.
  • Load Datasets Loads datasets from the database and associates them with the interface object.
  • Store Datasets Stores the datasets currently associated with the interface object into the database.
  • Miscellaneous API Methods Pointer Setup Specify the attributes of a the pointer, e.g., IN, IN/OUT, OUT, pooled, private. Pointer Attach Invoked each time a pointer address or size is modified
  • FIG. 2 presents a functional block diagram of the communication database 124 .
  • the communication database 124 includes a compiler 200 and an access engine 204 .
  • the communication database 124 parses standard interface definition files, such as in C, C++, or other programming language, and automatically extracts out the interface and tracing information.
  • the interface definition files contain the formats of the interfaces that are used for thread communication and software tracing. In one embodiment of the invention, a programmer can define these characteristics in the interface definition file via the use of compiler pragmas.
  • the information from the interface definition files is organized and stored in the communication database 124 such that it that can be accessed by other desktop applications via the host computer communication module 116 .
  • An exemplary process of building the communication database 124 is described below with respect to FIG. 9.
  • the DAT system 100 provides seamless and automatic ability for an application on the host computer 108 to make a remote function call to a routine that is on the embedded computer 104 and vice-versa, without requiring modification of the application other than to link the libraries and header files of the DAT system 100 .
  • An exemplary process of automatically generating code in support of a remote function call is described below with reference to FIG. 31.
  • FIG. 3 is a block diagram illustrating another exemplary embodiment of the invention.
  • the embodiment of the invention shown in FIG. 3 allows scripting languages to seamlessly access threads that are executing on the embedded computer 104 and the host computer 108 .
  • the DAT system 100 also comprises a messaging automation component (“MAC”) 304 and a script engine 312 for executing a script.
  • the MAC 304 is a COM-compliant object that provides interfaces for performing the following functions: designating ownership of an interface, generating a data set, sending a field of information, sending a data set, receiving a message, and listing each of the messages that are managed by the DAT system 100 .
  • the script engine 312 can be any proprietary or off-the-shelf engine that supports scripting languages such as: JavaScript, Visual Basic, VBScript, Tcl, JScript, Python, etc.
  • the application programming interfaces of the MAC 304 are set forth below.
  • ⁇ Dataset methods> Defined below Properties Name Name of the Interface SUID STRIDE Unique Identifier for the Interface Command Payload Command payload of the Message Object.
  • Un-register Un-register the object as a spy ⁇ Dataset methods> Defined below Properties Name Name of the Interface SUID STRIDE Unique Identifier for the Interface Command Payload Command payload of the Message Object. Response Payload Response payload of the Message Object. Out Pointer Data Out pointer data—defined as part of the Command payload, populated as apart of the Response.
  • Out Pointer Data Out pointer data—defined as part of the Parameter List, populated as apart of the Output.
  • Out Pointer Data Out pointer data—defined as part of the Parameter List, populated as apart of the Output.
  • Dataset properties Defined below Datasets Methods Clear All Datasets Clears/Deletes all datasets associated with either the Command or Response (Message Objects), or Input or Output (Function Objects) Delete Datasets Deletes a specified number of datasets Insert Datasets Inserts a specified number of datasets.
  • Load Datasets Loads datasets from the database and associates them with the interface object.
  • Store Datasets Stores the datasets currently associated with the interface object into the database.
  • datasets are sets of data associated with either the command (command payload) or response (response payload and out pointer data).
  • One-way messages have command datasets
  • broadcast messages have response datasets
  • two-way messages have both.
  • datasets are associated with either the input (parameter list) and/or the output (return value and out pointer data).
  • Scripting languages allow developers to customize, automate testing, and add macro capabilities. Scripting languages, in general, are easy to use for this type of functionality. Scripting languages also contain much of the same capability found in compiled languages such as loops, conditional statements, etc.
  • a script program is text written in a script language that is executed by a script engine.
  • the messaging automation component 304 provides a script program seamless and instant access to the communication interfaces of each of the threads in the embedded computer 104 and the host computer 108 . Using the messaging automation component 304 , fields in a message or parameters in a remote function call can be set, read, tested against, or used in expressions.
  • the scripting program can also transmit and receive communications seamlessly with software running on either an embedded computer 104 or the host computer 108 . Furthermore, establishing such communication does not require code changes of the threads executing on either the embedded computer 104 and/or the host computer 108 .
  • the script program is launched via an interface that is provided by the studio module 128 .
  • the script program does not have to be launched by the studio module 128 , but instead, can be launched and communicate directly with the host computer communication module 116 .
  • FIGS. 4A and 4B illustrate exemplary scripts that can execute in the script engine 312 to communicate with one of the threads 114 that are executing on the embedded computer 104 and/or the host computer 108 .
  • Code block 404 illustrates exemplary code that may be used to send a two way message.
  • the script sets an object “msg” equal to one of the messages that is maintained in the communication database 124 .
  • the script sets a field in a payload that is associated with the message. As is known in the art, a payload is structured data.
  • the script sends a command message and waits for a response.
  • the script retrieves the response data.
  • Code block 408 illustrates exemplary code that may be used to subscribe to a broadcast.
  • Code block 412 illustrates exemplary code that may be used to invoke a function.
  • Code block 416 illustrates exemplary code that may be used to register ownership of a function.
  • FIG. 5 is a block diagram illustrating another embodiment of the invention.
  • a COM composer 504 automatically builds a generated component 508 that serves as an interface between a COM-compliant application 512 and the host computer communication module 116 .
  • COM is a Microsoft technology that enables different applications to communicate with each other using a known interface, independent of the languages that the applications were developed in. For compatibility purposes, COM specifies the particular format and protocol of the interfaces.
  • the generated component 508 provides the COM-compliant application 512 seamless and instant access to the communication interfaces of an embedded application through predefined API. Using the generated component 508 , the COM-compliant application 512 seamlessly communicates with threads executing on the embedded computer 104 and the host computer 108 .
  • the host computer communication platform 116 automatically formats communication in a form suitable for its destination. An exemplary process of formatting a communication is described below with reference to FIG. 11.
  • Un-register Un-register the object as a spy ⁇ Dataset methods> Defined below Properties Name Name of the Interface SUID STRIDE Unique Identifier for the Interface Command Payload Command payload of the Message Object. Response Payload Response payload of the Message Object. Out Pointer Data Out pointer data—defined as part of the Command payload, populated as apart of the Response.
  • Out Pointer Data Out pointer data—defined as part of the Parameter List, populated as apart of the Output.
  • Out Pointer Data Out pointer data—defined as part of the Parameter List, populated as apart of the Output.
  • Dataset properties Defined below Datasets Methods Clear All Datasets Clears/Deletes all datasets associated with either the Command or Response (Message Objects), or Input or Output (Function Objects) Delete Datasets Deletes a specified number of datasets Insert Datasets Inserts a specified number of datasets.
  • Load Datasets Loads datasets from the database and associates them with the interface object.
  • Store Datasets Stores the datasets currently associated with the interface object into the database.
  • the MAC 304 , the studio module 128 , the generated component 508 can be utilized together to provide a communication system for various types of applications.
  • a scripting program in a first language can communicate with a scripting program in the same or a second language, a COM-compliant application 512 via the generated component 508 , a thread executing on the embedded computer 104 , a thread executing on the host computer 108 , and the studio module 128 .
  • a COM-compliant application can communicate with a scripting program via the MAC 304 , another COM-compliant application, a thread executing on the embedded computer 104 , a thread executing on the host computer 108 , and the studio module 128 .
  • a user can send and receive messages to and from the COM-compliant application 512 , a scripting program, a thread executing on the host computer 108 , a thread executing on the embedded computer 104 .
  • FIG. 6 is a representational block diagram illustrating one embodiment of the communication database 124 .
  • additional types of information may be added to the database and/or certain types of information may be omitted.
  • the communication database 124 includes a platform-specific configuration section 604 .
  • the platform-specific configuration section 604 contains embedded computer machine characteristics and host computer machine characteristics.
  • the characteristics can include items, such as: an indication of whether the platform is big or little Endian, enumeration sizes, pointer sizes, structure alignment boundaries, etc. It is noted that in one embodiment of the invention, the embedded computer machine characteristics and the host computer machine characteristics are stored in a location other than the communication database 124 , such as the host computer communication module 116 or the embedded computer 104 .
  • the communication database 124 also includes a messages section 608 and a prototypes section 610 .
  • the messages section 608 and the prototypes section 610 respectively describe the characteristics of each of the messages and remote function calls on the embedded computer 104 and the host computer 108 .
  • the characteristics can include: (i) the unique name and or identifier of the message; (ii) the total size of the message; (iii) the type of the communication, e.g., one-way message, two-way message, broadcast message, remote function call; and (iv) the types of data are passed as part of the communication.
  • a one way message is sent from a “user” of the communication to the “owner” of the communication.
  • a thread can request ownership of a message via a registration routine that is provided via an application programming interface of the host computer communication module 116 .
  • a two way message comprises a “command” that is sent from the user to the owner and a “response” that is sent from the owner to the user.
  • a broadcast message is sent to all threads that have registered to receive the broadcast.
  • the communication database 124 also includes a trace points section 612 for maintaining trace points.
  • the communication database 124 also includes a description of the data types that are supported by the messages identified in the messaging section 608 and the functions listed in the prototypes section 610 .
  • the data types section 616 includes: (i) a description of the data types in the data structures that are part of a message or remote function call, e.g., integer, character, Boolean, floating-point, arrays, etc; (ii) the field name of each of the elements in each of the messages; (iii) and a description of characteristics of embedded pointers that may be part of the message.
  • FIG. 7 is a block diagram illustrating an exemplary component hierarchy of the generated component 508 .
  • the COM-compliant object 512 initially accesses the generated component 508 via a root object 704 .
  • the COM-compliant object 512 can send commands and receive responses from particular messages and remote function calls that are defined in the communication database 124 .
  • the COM-compliant object has access to an object 708 that is associated with “MESSAGE 1” and an object 712 that is associated with “MESSAGE 2.”
  • the COM-compliant object 512 can send and receive payloads with threads that are executing on the embedded computer 104 .
  • FIG. 8 is a flowchart illustrating a process of modifying source code to communicate with the DAT system 100 .
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a programmer adds API calls to invoke a registration method that is provided by the DAT system 100 .
  • a registering thread provides a unique thread identification code.
  • the programmer adds API calls to invoke a read method that is provided by the DAT system 100 .
  • the programmer adds, where applicable, API calls to invoke a send method that is provided by the DAT system 100 .
  • the programmer adds API calls to “subscribe” to a message. Subscribing to a message allows a subscriber to bind to a specific message and thereafter receive all broadcast transmissions.
  • Other messaging APIs may be provided by the DAT system 100 such as for the following: sending a command; sending a response; broadcasting a message; and defining the data (content) and meta-data (characteristics) of the payload of a message.
  • FIG. 9 is a block diagram illustrating an exemplary process of building the communication database 124 . Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. In one embodiment of the invention, the process shown in FIG. 9 is performed in response to a user request.
  • the studio module 128 reads and extracts information from each of a plurality of interface definition files that are provided by the user.
  • the studio module 128 extracts the communication interfaces from each of the interface definition files.
  • Information that is extracted can include: (i) the type of the communication, e.g., one-way, two-way, broadcast, remote function call; (ii) the types of data are passed as part of the communication; (iii) a description of the data types in the data structures that are part of a message or remote function call, e.g., integer, character, Boolean; (iv) a description of characteristics of embedded pointers that may be part of the message, e.g., whether the memory is “pooled” or “private”, a method of transmitting the memory that is associated with the communication interface, and pointer data that is associated with the communication interface.
  • the studio module 128 stores the embedded computer machine characteristics.
  • the embedded computer machine characteristics can be provided by user entry, automatic diagnosis of the embedded computer 104 , or automatically provided by the embedded computer 104 . Examples of the embedded computer machine characteristics are described above with respect to FIG. 6. In one embodiment, it is assumed that these characteristics are fixed, i.e., exactly the same on each connection.
  • the studio module 128 stores the host computer machine characteristics.
  • the host computer machine characteristics can be provided by user entry or automatic diagnosis of the host computer 108 . Examples of the host computer machine characteristics are described above with respect to FIG. 6.
  • FIG. 10 is a flowchart illustrating a process of using the DAT system 100 . Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the DAT system 100 receives registration information from each thread.
  • the DAT system receives a payload for a particular message.
  • the DAT system 100 formats the payload for transmission to its destination thread. It is noted that if the destination thread is local to the transmitting thread, then formatting may be unnecessary. An exemplary process of formatting data for transmission to a remote platform is described below with reference to FIG. 11. Moving to a step 1016 , the DAT system 100 transmits the formatted payload to the destination thread.
  • FIG. 11 is a flowchart illustrating a process of formatting data for use on an different platform. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. In one embodiment of the invention, the process that is performed by FIG. 11 is performed by the host computer communication module 116 of the DAT system 100 . Furthermore, FIG. 11 is directed to a process of formatting a payload for transmission from one platform, e.g., the host computer 108 to another, e.g., the embedded computer 104 .
  • the DAT system 100 performs all data formatting on the host computer 108 .
  • the host computer 108 uses the platform characteristics of the embedded computer 104 and the host computer 108 and the individual interface definition information (“the communication interface information”) to properly map messages when two applications on the different computers are communicating.
  • the embedded computer 104 always sends and receives messages in its native form, i.e., the form in which the message is stored in its memory.
  • the host computer 108 maps these messages into its form when receiving them, and transforms the messages into the embedded computer 104 platform's native form when transmitting the messages to the embedded computer 104 .
  • the host computer communication module 116 determines whether the destination thread is local or remote. If the thread is local, the process proceeds to a step 1108 and the payload is queued for transmission to the destination thread. If the transmission is local, no further modification of the payload is necessary.
  • step 1112 the host computer communication module 116 copies data in payload and data referenced by pointers into a message for transmission to the embedded computer 104 .
  • An exemplary process of managing pointer data is described in further detail below with reference to FIGS. 12A, 12B, 12 C, and 12 D.
  • the host computer communication module 116 formats, if necessary, the byte order of the elements in data in the payload. For example, if the host computer 108 is Big Endian, and the embedded computer 104 is Little Endian, or vice-versa, the host computer communication module 116 reverses the order of the bits in the data.
  • the host computer communication module 116 formats the size of the data types in the payload. For example, if the embedded computer 104 uses a certain bit-length for certain data types and the host computer uses a different bit-length, the host computer communication module 116 adjusts the size of the data for transmission to the other platform. Moving to a step 1128 , the host computer communication module 116 adjusts alignment of the data structures according to any requirement of the receiving platform.
  • FIGS. 12 A- 12 D each illustrate an exemplary method of managing pointers in a payload that are passed from one platform to another.
  • FIG. 12A is directed to a process of receiving a payload from a thread on the embedded computer 104 in connection with a “command” message.
  • FIG. 12A is performed with respect to each of the pointers in the payload.
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the method shown in FIG. 12 is performed by the host computer communication module 116 .
  • a similar process as shown in FIG. 12 is performed on the embedded computer communication module 112 when the embedded computer communication module 112 receives a command message.
  • the embedded computer communication module 112 does not perform any of inter-platform formatting of the received data as such formatting is performed by the host computer communication module 116 .
  • a thread on the embedded computer 104 has invoked a send command that is part of the application programming interface of the embedded computer communication module 112 .
  • the embedded computer communication module 112 has built and then transmitted an inter-platform message to the host computer communication module 116 .
  • the inter-platform message includes the payload that was identified as part of the send command and, if applicable, the data that is referenced by the pointers in the payload.
  • the host computer communication module 116 gets the embedded pointer attributes of a selected pointer in the payload of the transmitted communication.
  • the attribute information is stored in the transmitted communication.
  • a first attribute of each pointer is whether the pointer is classified as “IN”, “OUT”, or “IN/OUT”.
  • the “IN” attribute designates that the data referenced by the pointer is passed from the sender of the command to the owner of the message but no data is to be returned by the owner of the message.
  • the “OUT” attributes designates that the sender of the command will not transmit any data that is referenced by the pointer but data will be returned by the owner and stored in the address referenced by the pointer.
  • the “IN/OUT” attribute indicates that the data that is referenced by the pointer will be sent from the sender of the command and that the owner of the message will return data that is stored in the memory referenced by the pointer.
  • a second attribute of each pointer is whether the pointer is “private” or “pooled.” Management (freeing of the memory when not in use) of “private” memory is handled by the DAT system 100 . Management of “pooled” memory is handled by the user and/or the owner of a message.
  • the host computer communication module 116 creates a local buffer to hold the pointer data.
  • the host computer communication module 116 determines whether the pointer attribute is either “IN” or “IN/OUT”. If the pointer attribute is “IN” or “IN/OUT”, the process proceeds to a step 1214 .
  • the host computer communication module 116 copies the pointer data that was transmitted from the embedded computer 104 into the local buffer.
  • the host computer communication module 116 formats the pointer data in accordance with the process described above with reference to steps 1116 , 1124 , and 1128 .
  • the host computer communication module 116 copies the address of the buffer into the payload. Proceeding to a decision step 1220 , the host computer communication module 116 determines whether the first attribute of the pointer is “IN”. If the first attribute of the pointer is “IN” the process proceeds to a decision step 1222 . At the decision step 1222 , the host computer communication module 116 determines whether the second attribute of the pointer is “private”. If the second attribute of the pointer is private, the process proceeds to a step 1228 . Otherwise if the second attribute of the pointer is not private, i.e., pooled, the process ends.
  • the host computer communication module 116 copies the address of the local buffer into the payload. From step 1216 , or from decision step 1220 (if the first attribute is “IN/OUT”), the process proceeds to a step 1224 . At this step, the host computer communication module 116 waits for thread on the host computer 108 to invoke a response command that is provided by the application programming interface of the DAT system 100 . Upon receiving the response, the process proceeds to a step 1226 . At this step, the response data is formatted for transmission to the embedded computer 104 .
  • step 1226 From either step 1226 or from the decision step 1222 (if the second attribute of the pointer is “private”), the process proceeds to a step 1228 wherein the host computer communication module 116 waits for a thread on the host computer 104 to invoke a read complete command that is in the application programming interface of the host computer communication module 116 . Upon receipt of the read complete command, the process proceeds to a step 1230 wherein the host computer communication module frees the memory.
  • FIG. 12B is directed to a process of managing pointers in a payload in a command message that is sent from a thread on the host computer 108 to a thread on embedded computer 104 .
  • FIG. 12B illustrates in further detail the steps that occur in step 111 of FIG. 11.
  • FIG. 12B is performed with resect to each of the pointers in the payload.
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a similar process is performed by the embedded computer when transmitting a command message from a thread on the embedded computer 104 to the host computer 108 .
  • the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • the host computer communication module 116 creates a buffer to hold an inter-platform message for transmission to the embedded computer 104 . Also, at this step, the host computer communication module 116 creates a header in the inter-platform message for the embedded pointer. Furthermore, at this step, the host computer communication module 116 stores the pointer attributes of the pointer in the inter-platform message.
  • the host computer communication module 116 determines whether the pointer attribute of the pointer is “OUT”. If the attributes of a selected pointer is “OUT”, the process ends. However, if the pointer attribute is not “OUT”, i.e., it is “IN” or “IN/OUT”, the process proceeds to step 1244 .
  • host computer communication module 116 copies the data referenced by the pointer into the header. Furthermore, the host computer communication module 116 formats the data for use by a thread on the embedded computer 108 . For example, the host computer communication module performs the steps described above with respect to steps 1116 , 1124 , and 1128 .
  • the host computer communication module 116 determines whether the pointer attributes is “IN.” If the pointer attribute is “IN”, the process proceeds to a step 1240 . At this step, the host computer communication module 116 frees the memory, if warranted, i.e., the attributes of the pointer designate “pool”. However, if the pointer attribute is not “IN”, the proceeds ends.
  • FIG. 12C is directed to a process of receiving a response message from the embedded computer communication module 112 .
  • FIG. 12C illustrates in further detail the steps that occur in step 111 of FIG. 11.
  • FIG. 12C is performed with resect to each of the pointers in the payload.
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a similar process is performed by the embedded computer 104 when transmitting a command message from a thread on the embedded computer 104 to the host computer 108 .
  • the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • a thread on the embedded computer 104 has invoked a send response command that is part of the application programming interface of the embedded computer communication module 112 .
  • the embedded computer communication module 112 has built and then transmitted an inter-platform message to the host computer communication module 116 .
  • the inter-platform message includes the payload that was identified as part of the send response and, if applicable, the data that is referenced by the pointers in the payload.
  • the host computer communication module 116 determines whether the pointer attributes of the pointer in the inter-platform message designate the attribute “IN”. If the pointer attributes designate the attribute “IN”, the process proceeds to a step 1252 , and the host computer communication module 116 formats the received data for use with the host computer 108 . For example, in one embodiment, the host computer communication module 116 performs the steps described above with respect to steps 1116 , 1124 , and 1128 .
  • the process proceeds to a step 1254 .
  • the host computer communication module 116 creates a local buffer to store the pointer data that was transmitted by the embedded computer 104 .
  • the host computer communication module 116 copies the pointer data from the inter-platform communication into the local buffer.
  • the host computer communication module 116 copies the address of the buffer into the received payload.
  • the host computer communication module 116 determines whether it should free the pointer. In one embodiment of the invention, this is determined by reading the pointer attributes. If the pointer attributes designate “private” the host computer communication module 116 decides to free the memory. However, if the pointer attributes designate “pooled” the host computer communication module 116 allows the user to free the memory.
  • step 1260 If the host computer communication module 116 determines in step 1260 to free the memory, the process proceeds to a step 1262 , wherein the host computer communication module 116 waits for a thread on the host computer 108 to invoke the read complete command. Continuing to a step 1264 , the host computer communication module 116 frees the local buffer. From either decision step 160 (if the host computer communication module 116 does not free the pointer) or the step 1264 the process ends.
  • FIG. 12D is directed to an exemplary process of managing pointers in a payload in a response message that is sent from a thread on the host computer 108 to a thread on embedded computer 104 .
  • FIG. 12D illustrates in further detail the steps that occur in step 1112 of FIG. 11.
  • FIG. 12D is performed with resect to each of the pointers in the payload.
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a similar process is performed by the embedded computer 104 when transmitting a response message from a thread on the embedded computer 104 to the host computer.
  • the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • a thread on the embedded computer 104 has sent a command message and a thread on the host computer 108 has responded by invoking the send response routine of API of the DAT system 100 .
  • the host computer communication module 116 allocates space in an outgoing buffer (“a header”) to store the data that is referenced by the pointer.
  • the outgoing buffer is part of an inter-platform message that is sent from the host computer communication module 116 to the embedded computer communication module 112 .
  • the host computer communication module 116 determines whether the pointer attributes designate “IN”. If the pointer attributes do designate “IN”, i.e., they do not designate “OUT” or “IN/OUT”, the process proceeds to a decision step 1267 .
  • the host computer communication module 116 determines whether to free memory that is associated with the memory that was allocated during the corresponding send command.
  • this is determined by reading the pointer attributes. If the pointer attributes designate “pool” the host computer communication module 116 decides to free the memory. However, if the pointer attributes designate “private” the host computer communication module 116 allows the user to own and eventually free the memory (via an routine provided by the local operating system). If the host computer communication module 116 determines it should free the memory, the process proceeds to a step 1268 , and the host computer communication module 116 frees the memory. From either step 1268 or decision step 1266 (if the pointer attributes does not designate “IN”), the process proceeds to a step 1270 and the host computer communication module 116 formats the data referenced by the pointer for transmission to the embedded computer. For example, in one embodiment, the host computer communication module 116 performs the steps described above with respect to steps 1116 , 1124 , and 1128 . As part of the formatting, the formatted data is stored in the header (step 1265 ).
  • FIG. 13 is flowchart illustrating a process of using the DAT system 100 from a script in the script engine 312 .
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the studio module 128 has received a request from a user to load a script file and it does so here.
  • studio determines script type that is associated with the script file.
  • the script type can be determined in different ways, including examining the extension of the identified script file or from the contents of the script itself.
  • Exemplary types of scripting languages include: JavaScript, Visual Basic, VBScript, Tcl, JScript, Python, etc.
  • the studio module 128 identifies the corresponding script engine 312 that is associated with the script type. Continuing to a step 1320 , the studio module 128 initializes the script engine 312 .
  • the studio module 128 loads the messaging automation component (“MAC”) 304 .
  • the process of loading the MAC 304 is described below with reference to FIG. 14. Proceeding to a step 1328 , the MAC 304 is “exposed” to the script engine 312 . In one embodiment of the invention, exposing the MAC 304 includes providing the script engine 312 a handle to the MAC 304 .
  • the script engine is launched, allowing the script loaded in a step 1304 to access the API of MAC 304 .
  • a script program can communicate with threads 114 using the API of the MAC 304 . An exemplary process of using the MAC 304 is described below with respect to FIG. 15.
  • FIG. 14 is a flowchart illustrating a process of loading the MAC 304 .
  • FIG. 14 illustrates in further detail the steps that occur in step 1324 of FIG. 13.
  • the studio module 128 calls the initialization routine of the MAC 304 and passes as a parameter a handle to the communication database 124 .
  • the MAC 304 generates a messaging automation component “MAC” database object.
  • the MAC database object contains certain of the information from the communication database 114 .
  • the MAC database is used by the scripting program to access application programming interfaces of the MAC 304 .
  • FIGS. 15 - 17 are flowcharts illustrating a process of communicating with the MAC 308 using a scripting language. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • FIG. 15 is a flowchart directed to a process of registering a particular message with the MAC 304 .
  • a script that is executing in the scripting engine 312 invokes a register method of the MAC 304 .
  • the MAC object calls the register API of the host computer communication module 116 .
  • FIG. 16A is a flowchart illustrating a process of sending a message via the MAC 304 .
  • the script retrieves reference to a MAC database object.
  • the script requests the MAC database object to provide a reference to a message object.
  • the message object is used by the script program to communicate with a owner of a communications or to receive communications from others.
  • a script can set fields of the message, send a message, receive a message, and perform other standard messaging functions.
  • the MAC database object retrieves the message definition information from the communication database 124 .
  • the message definition information is retrieved via the host computer communication module 116 .
  • the message definition information is retrieved directly from the communication database 124 .
  • the message definition information includes: (i) the type of the communication, e.g., one-way, two-way, broadcast, remote function call and (ii) the types of data that are passed as part of the communication.
  • the MAC database object creates a MAC message object based upon the prototype definition retrieved from the communication database 124 .
  • the MAC database object retrieves any data sets from the communication database that are stored with respect to the requested message object.
  • the MAC database object adds the data sets to the message object (created in step 1614 ).
  • the MAC database object returns a reference to the message object to the script.
  • the script can set the data fields of the message using reference to the message object.
  • the script has access via the MAC database object to a plurality of readable and writeable data sets.
  • the script can identify one of the data sets for subsequent usage.
  • the script invokes a send method of the method object. Proceeding to a step 1636 , the MAC database object sends a data set that is referenced by the current index to the thread that owns the message.
  • the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1644 , and the MAC database object selects the next data set. Referring again to the decision step 1640 , if auto-increment is not enabled, the process ends.
  • FIG. 16B is a flowchart illustrating a process of invoking a function via the MAC 304 .
  • the script retrieves reference to the MAC database object.
  • the script requests the MAC database object to provide a reference to a remote function call object.
  • the remote function call object is used by the script program to communicate with the thread that handles the remote function call.
  • a script can set the parameters that will be passed upon invoking the remote function call.
  • the MAC database object retrieves the remote function call prototype definition information from the communication database 124 .
  • the prototype definition information is retrieved via the host computer communication module 116 .
  • the message definition information is retrieved directly from the communication database 124 .
  • the MAC database object creates a MAC remote function call object based upon the remote function call prototype definition retrieved from the communication database 124 .
  • the MAC database object retrieves any data sets from the communication database that are stored with respect to the requested remote function call object.
  • the MAC database object adds the data sets to the MAC remote function call object.
  • the MAC database object returns a reference to the remote function call object to the script.
  • the script can set the data fields (parameters) of the remote function call using the remote function call object.
  • the script has access via the MAC database object to a plurality of readable and writeable data sets.
  • the script can identify one of the data sets for subsequent usage.
  • the script invokes a call method of the remote function call object.
  • the MAC database object sends a data set that is referenced by the current index to the thread that handles the remote function call.
  • the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1678 , and the MAC database object selects the next data set. Referring again to the decision step 1676 , if auto-increment is not enabled, the process ends.
  • FIG. 17A is a flowchart illustrating a process of a script receiving a message via the MAC 304 .
  • additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the script calls a read method of the MAC database object.
  • the MAC database object calls a read API of the host computer communication module 116 .
  • the host computer communication module 116 waits for a message to be received.
  • the MAC database object receives the message and a message identifier from the host computer communication module 116 .
  • the MAC database object returns a message object to the script, which can in turn access the contents of the requested message.
  • FIG. 17B is a flowchart illustrating a process of a script receiving a communication via function call application programming interfaces that are provided by the MAC 304 . Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the script calls a read method of the MAC database object.
  • the MAC database object calls the read API of the host computer communication module 116 .
  • the MAC database object waits for a remote function call command message to be received.
  • the MAC database object receives the remote function command message and the function identifier.
  • a remote function call object is returned to the script program.
  • the script program access the input parameters of the remote function call object.
  • the MAC database object returns a reference to the remote function call object to the script.
  • the script invokes a return method of the remote function call object.
  • the remote function call object calls the send application programming interface of the host computer communication module 116 .
  • the MAC database object sends a data set that is referenced by the current index to the thread that handles the remote function call.
  • the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1778 , and the MAC database object selects the next data set. Referring again to the decision step 1776 , if auto-increment is not enabled, the process ends.
  • FIG. 18 is a flowchart illustrating a process of interfacing with the DAT system 100 from any COM-compliant language. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a user loads “launches” the COM composer tool 504 (FIG. 5). An exemplary process of loading the COM composer tool is described below with reference to FIG. 19.
  • the COM composer builds the generated component 508 (FIG. 5).
  • the generated component 508 is a COM object that is accessible by other COM compliant programs.
  • a COM-compliant program can easily: test a interface, send a communication to a thread that is executing on the embedded computer 104 or the host computer 108 , receive a communication that is sent from a thread this executing on the embedded computer or the host computer 108 , and other functions as described herein.
  • the generated component 508 provides a plurality of predefined interfaces for performing each of the foregoing functions. An exemplary process of building the generated component 508 is described below with reference to FIG. 20.
  • the generated component 508 is accessible via any COM-compliant language.
  • An exemplary process of using the generated component is described below with reference to FIG. 22.
  • FIG. 19 is a flowchart illustrating an exemplary process of launching the COM composer tool 504 .
  • FIG. 19 illustrates in further detail certain steps that occur in step 1804 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a user identifies a database.
  • the DAT system 100 can support multiple databases for multiple projects.
  • the user selects which messages or functions of the selected database are to be included in the generated COM object.
  • the user selects the messages and/or remote function calls via a graphical user interface utility.
  • the user selects the compiler version.
  • the COM composer 504 needs to know the version of the compiler that is being used to build the generated component 508 to provide the proper control files in the proper format.
  • the COM composer 504 requests the user to designate the type of build, e.g., release or debug.
  • FIG. 20 is a flowchart illustrating an exemplary process of building the generated component 508 .
  • FIG. 20 illustrates in further detail certain steps that occur in step 1808 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the COM composer tool loads the data that was identified by the user (step 1904 ) into memory.
  • the COM composer tool begins a process that is performed with respect to the following: (i) all of the messages and/or remote function calls identified by the user (step 1908 ), (ii) all of the payloads of the identified messages and/or remote function calls, and (iii) the root object that is used to access all other objects in the generated component 508 .
  • steps 2012 , 2016 , 2020 , and 2024 are performed for each of the foregoing objects.
  • the COM composer 504 generates a software interface for each of the objects.
  • An exemplary process of generating an interface is described below with reference to FIG. 21.
  • the generated component generates a COM class definition for the object, otherwise known as a co-class.
  • the COM composer generates a COM class implementation for each of the COM objects.
  • the COM composer 504 determines whether it has processed all of the messages/remote function calls, payloads, and the root object. If all of these items have not been processed, the process returns to the step 2012 (discussed above). However, if all of the items have been processed, the COM composer 504 proceeds to a step 2028 and provides any compiler specific files that are needed, if any.
  • the COM composer 504 launches the selected compiler to build the generated component 508 .
  • the COM component is provided in a dynamic link library “.DLL”.
  • the COM composer 504 registers the dynamic link library with a registry in the host computer 108 .
  • FIG. 21 is a flowchart illustrating a process of generating an interface.
  • FIG. 21 illustrates in further detail the steps that occur in step 2012 of FIG. 20. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the COM composer 504 starts at a step 2104 , the COM composer 504 generates method definitions for “built-in” member functions.
  • the COM composer 504 generates accessor function for child objects 2108 .
  • the children of the root object includes each of the messages and/or remote function calls.
  • the children of a message object and/or a remote function call object includes one or more payloads that are associated with the object.
  • the COM composer 504 generates interface for setting and getting properties of objects.
  • FIG. 22 is a flowchart illustrating a process of using the generated component 508 .
  • FIG. 22 illustrates in further detail certain steps that occur in step 1816 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the user Before starting at a step 2216 , the user has opened a COM development environment and located the via the COM development environment the generated component 508 .
  • the user creates a reference to the generated component 508 .
  • the user creates an instance of the root object.
  • the user can use the root object accessor function to retrieve a desired message object or remote function call object.
  • the user can use the accessor function of the object to select a desired payload object.
  • the user invokes a method of the payload object to get or set properties of the payload object. For, example, the user can store data in the payload object.
  • the user invokes methods on the message object or the remote function call object to send a communication. The user may also invoke other methods on a message object such as register the message such any broadcast on the message is received by the invoking process. Other methods are described above with reference to FIG. 5.
  • the user implements an event handler to receive asynchronous communications that are received, if any.
  • FIG. 23 is a flowchart illustrating a process of using the studio module 128 .
  • the studio module 128 provides a graphical user interface control panel for testing each of the communication interfaces that are identified by the communication database 124 .
  • a user loads a selected communication database 124 .
  • a user may have different communication databases for different projects. Once loaded, a user may view and select any of the communication interfaces in the communication database 124 .
  • the user can perform a number of functions with respect to the database such as: designating ownership of a communication interface (step 2312 ), generating a data set (state 2316 ), sending a field of information (step 2320 ), and sending a data set (step 2324 ).
  • FIG. 24 is a flowchart illustrating a process of generating a data set based upon monitoring the communication between two threads executing under the DAT system 100 . It is noted that the process of generating a data set can be initiated by a user either: (i) the studio module 128 , (ii) C language source code that invokes a method of the host computer communication module 116 , (iii) a script executing in the script engine 312 , or (iv) a COM-compliant application via the generated component 508 .
  • the user specifies the communication data paths that are to be traced.
  • the DAT system 100 can trace that data is sent via a message or via a remote function call.
  • the DAT system 100 monitors and stores the data that is transmitted across each of the designated communication paths.
  • the data is stored in a persistent test data object.
  • any thread can then select and retrieve the contents of any of persistent test data objects and use the data for testing.
  • one of the threads of the DAT system 100 uses one of the persistent data object to transmit data from one of the selected persistent data object across one of the communication data paths.
  • FIG. 25 illustrates an exemplary user interface 2500 that is provided by the studio module 128 .
  • the user interface 2500 includes an interface window 2504 that lists all of the interfaces that are maintained in the communication database 124 . Each entry in the in the interface list is selectable by a user.
  • a communication window 2508 is displayed on the screen.
  • the communication window 2508 includes an register icon 2510 that allows a user to register ownership of a message or remote function call.
  • the communication window is divided into a command window 2508 and a response window 2510 .
  • the command window and the response window include one or more data set fields 2512 .
  • the number of data set fields is configurable by the user.
  • the data sets show the contents of the most recent payload and a user configurable number of previously received payloads.
  • the user can build a payload for a particular command message and set the payload of the response message. Furthermore, the user can select a “store data set” icon 2514 to store the values in the data set fields 2512 in the communication database 124 . Later, the user can select a “load data set” icon 2516 to load the stored values. Furthermore, the user may select a clock icon 2518 to have the studio module 128 automatically iterate and transmit the data values in sequence at a user configurable time interval.
  • FIG. 26 illustrates an exemplary user interface 2600 that allows a user to view and test the parameters that are transmitted as part of a function call.
  • a user can register ownership of a function.
  • a user window 2608 displays a plurality of parameter fields 2610 that allow a user to set the values of parameters in the function.
  • An owner window 2610 displays the parameters that have been passed to the function.
  • the user interface 2600 allows the saving and loading of data sets as described above with reference to FIG. 25.
  • FIG. 27 is a flowchart illustrating a process of automatically generating templates of source code for use with the embedded computer communication module 112 or the host computer communication module 116 .
  • the process of FIG. 27 is performed by the studio module 128 .
  • the process of FIG. 37 is performed by a standalone tool, such as a code generator.
  • a code generator For convenience of description, the following description refers to a code generator. However, it is to be appreciated that such function could be provided by the studio module 128 or the communication database 124 . Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • the user identifies one or more interface definition files that define the communication interface. For example, in code block 3200 of FIG. 32 illustrates a portion of an interface definition file.
  • a code generator provides a graphical user interface utility for selection of the communication interfaces.
  • a code template of a “thread” is generated for handling each of selected messages in the interface definition file.
  • An exemplary process of generating a thread is described below with reference to FIG. 28.
  • An exemplary template is shown in code block 3204 of FIG. 32.
  • a template of a thread is generated for each of the selected functions in the interface definition file.
  • An exemplary process of generating a thread is described below with reference to FIG. 31.
  • An exemplary template is shown in code block 3204 of FIG. 32.
  • FIG. 28 is a flowchart illustrating a process of generating a thread for each of the identified messages in an interface definition file.
  • FIG. 28 illustrates in further detail the steps that occur in step 2716 of FIG. 27. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • a message handling routine is created to handle all messages that have been identified by the user.
  • the message handling routine includes a loop and, subsequent to the loop, a switch statement. See e.g., code block 3204 .
  • a loop is entered and steps 2804 , 2808 , and 2812 are performed for each of the identified messages.
  • the code generator adds a line of code to register each of the messages. See e.g., code block 3204 .
  • the source code includes code to invoke a registration routine that is provided by the embedded computer communication module 112 or the host computer communication module 116 . The call to invoke the registration route is placed prior to the generated switch statement.
  • the code generator generates message handling code for each of identified messages.
  • An exemplary process of generating message handling code is described below with reference to FIG. 29.
  • the code generator creates routines for sending a message.
  • An exemplary process of creating a routing for sending a message is described below with reference to FIG. 30.
  • FIG. 29 is a flowchart illustrating a process of generating message handling code.
  • FIG. 29 illustrates in further detail the steps that occur in step 2908 of FIG. 28. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. The process shown in FIG. 29 is performed with respect to each of the messages identified by the user in step 2708 of FIG. 27.
  • the code generator starts at a step 2904 , the code generator generates a case statement. Proceeding to a step 2908 , the code generator generates a comment to the user to instruct the user to add code.
  • the code generator determines whether the message is “two-way”. If the message is “two-way”, the process proceeds to a step 2916 . Otherwise, the process proceeds to a step 2920 .
  • the code generator adds code in the generated case statement to invoke a send response routine.
  • code block 3204 of FIG. 32 includes a call to the “SendMesessageTwoWayResponse” routine.
  • the process of generating a response routine such as the “SendMesessageTwoWayResponse” routine, is described below with reference to 3016 of FIG. 30.
  • the generated code will invoke an API, e.g., SendResponse(), of the DAT system 100 .
  • the code generator may also generate other APIs for convenience of the user, e.g., routines to setup and attach pointers.
  • the code generator may also generate code to invoke a release routine that is provided by the API.
  • FIG. 30 is a flowchart illustrating a process of generating a template of a routine for sending a message via the communication interface identified by the user in step 2708 of FIG. 27.
  • FIG. 30 illustrates in further detail the steps that occur in step 2812 of FIG. 28.
  • the code generator determines whether the message is one-way, two-way, or broadcast. If the message is one-way or two-way, the process proceeds to a step 3010 .
  • the code generator generates a function to send a command to invoke a send command.
  • An exemplary generated code template is shown in code block 3208 of FIG. 32.
  • the code generator determines whether the communication is one-way or two-way. If the message is not one-way, i.e., two-way, the process proceeds to a step 3016 .
  • the code generates a function for sending a response. The generated code invokes the API to send a response.
  • the code generator determines whether message is a broadcast message. If the message is a broadcast, the process proceeds to a step 3020 . At the step 3020 , the code generator adds code to invoke an broadcast routine that is part of the API of the embedded computer communication module 112 and the host computer communication module 116 . From steps 3012 (if the communication is “one-way”), 3020 , and 3016 the process proceeds to a step 3024 . At the step 3024 , the code generator determines whether there are pointers present in the payload of the message. If pointers are present, the process proceeds to a step 3028 .
  • the code generator generates code to invoke a pointer setup command that is part of the communication library API.
  • the code generator generates code to invoke the API attach pointer. It is noted that the generated commands during steps 3032 and 3028 are inserted into the generated code prior to the generated send response command (step 3016 ).
  • FIG. 31 is a flowchart illustrating a process of generating template code for communicating across platforms via a remote function call.
  • inter-platform function calls invoke a local function that communicates with the remote function of the same name via messaging that is provided by the embedded computer communication module 112 and the host computer communication module 116 .
  • a loop is performed with respect to steps 3108 , 3112 , and 3116 .
  • template code is generated for exestuation on a local platform, i.e., either the embedded computer 104 or the host computer 108 .
  • the local platform in this context is defined to be the computer that does not have the routine that is to be invoked.
  • Steps 3108 , 3112 , and 3116 are performed with respect to each of the functions identified by the user in step 2708 of FIG. 27.
  • the code generator generates a send command.
  • the code generated generates a read command. Proceeding to a step 3116 , the code generator generates code to return a response.
  • An exemplary code block resulting from steps 3108 , 3112 , and 3116 is shown in code block 3212 of FIG. 33.
  • a loop is performed with respect to steps 3124 , 3128 , 3132 , 3136 , and 3140 .
  • template code is generated for execution on the remote platform.
  • the code generator generates code to invoke a registration routine of the API.
  • the code generator generates code that invokes the local API that was requested by the thread on the other platform and sends a response message.
  • An exemplary code block resulting from steps 3124 , 3218 , 31332 , 3136 , and 3140 is shown in code block 3214 .
  • the code generator determines whether there are any pointers in the parameters of the function. If there are no pointers in the parameters of the function, the process ends. However, if there are pointers, the process proceeds to a step 3136 and the code generator generates code to invoke the API to setup a pointer. Moving to a step 3140 , the code generator generates code to invoke the API to attach a pointer. The process then ends.
  • the DAT system 100 provides a single virtual environment that enables threads to be located on different platforms and still seamlessly communicate with each other.
  • the DAT system 100 provides communication interoperability between the two platforms by automatically transforming the data depending on the machine characteristics of the embedded computer 104 , the host computer 108 , and the communication interfaces that are stored in the communication database 124 .
  • the DAT system 100 provides automatic and seamless access to the message-based and remote function call interfaces designed into the embedded computer's software application.
  • the DAT system 100 automatically extracts interface information and builds a database of messaging and remote function call information.
  • a user Using the studio module 128 , a user has complete visibility and control of the embedded application's interfaces without having to address the following issues: (i) updates to a desktop tool to accommodate new messages; (ii) updates to the embedded software to support the desktop tool's new functionality; (iii) what target compiler is used; (iv) what RTOS is used; and (iv) what platform the thread(s) are executing on.
  • the DAT system 100 allows seamless access to interfaces stored in the communication database 124 via scripting languages or any COM-compliant application.

Abstract

A system and method for providing seamless communication with threads executing on an embedded computer. Using a DAT system, a programmer can test the communication interfaces of a thread via either a scripting program, any COM-compliant program, or a graphical test utility. The DAT system automatically formats a block of data that is transmitted between the embedded computer and a host computer and accounts for machine specific enumeration sizes, machine specific pointer sizes, machine specific structure alignment boundaries, machine specific integer sizes, and machine specific byte ordering.

Description

    RELATED APPLICATIONS
  • This application claims priority to, and incorporates by reference, in their entirety, the following applications: U.S. Provisional Application No. 60,278,212, filed Mar. 23, 2001, titled “SYSTEM FOR DEBUGGING AND TRACING THE PERFORMANCE OF SOFTWARE TARGETED FOR EMBEDDED SYSTEMS” and U.S. Provisional Application No. 60/299,555, filed Jun. 18, 2001, titled “MESSAGING SYSTEM AND PROCESS”, and U.S. Provisional Application No. ______, filed Mar. 11, 2002, titled “DEVELOPMENT AND TESTING SYSTEM AND METHOD.”[0001]
  • This application is related to and incorporates by reference in their entirety, the following commonly owned patent applications that have been filed on even date herewith: U.S. patent application Ser. No. ______, titled “SYSTEM AND METHOD FOR FORMATTING DATA FOR TRANSMISSION BETWEEN AN EMBEDDED COMPUTER AND A HOST COMPUTER HAVING DIFFERENT MACHINE CHARACTERISTICS”; U.S. patent application Ser. No. ______, titled “SYSTEM AND METHOD FOR BUILDING A DATABASE DEFINING A PLURALITY OF COMMUNICATION INTERFACES”; U.S. patent Application Ser. No. ______, titled “SYSTEM AND METHOD FOR PROVING AN INTERFACE FOR SCRIPTING PROGRAMS TO COMMUNICATE WITH EMBEDDED SYSTEMS”; U.S. patent application Ser. No. ______, titled “SYSTEM AND METHOD FOR GENERATING DATA SETS FOR TESTING EMBEDDED SYSTEMS”; and U.S. patent application Ser. No. ______, titled “SYSTEM AND METHOD FOR AUTOMATICALLY GENERATING CODE TEMPLATES FOR COMMUNICATION VIA A PREDEFINED COMMUNICATION INTERFACE”. [0002]
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0003]
  • The field of the invention relates to development and testing. More particularly, the field of the invention relates to the development and testing of software. [0004]
  • 2. Description of the Related Technology [0005]
  • An embedded device typically includes a microprocessor and application software. The application software runs under the control of a real-time operating system (RTOS) and is typically partitioned into one or more threads. A thread is an independent unit of executable software that shares the control of the microprocessor with other defined threads within the embedded system. In many embedded devices, a thread is allocated its own stack space, given a “priority”, and assigned other resources that enable the thread to run as an “independent” entity. Stack space is a section of memory reserved for temporary storage of local variables. Priorities are used by the RTOS to determine which thread gets control of the microprocessor if more than one thread is waiting. Resources can include miscellaneous items such as queues, flags, etc., that are required by the RTOS to manage a thread. Other common terms used for a thread are “task” and “process.” A process also implies a separate address space which protects different processes from adversely affecting each other. An example of a process running on a desktop computer using Microsoft's Windows Operating System (OS) is Microsoft Word. [0006]
  • A common method for threads to communicate with each other is via a messaging application programming interface (API) that is provided by the operating system. A message typically includes an event and optionally a block of data that is sent between at least two threads. For example, a thread (“the sender”) builds a message and invokes a specific API from the RTOS. The RTOS notifies the other thread (“the receiver”) that some type of event has occurred. The receiving thread then reads the incoming message. Another common method for threads to communicate is via a function call. Using a function call provided by one thread can be invoked by another thread. Likewise functions can be called by other functions that co-exist in the same thread. Other common terms for a function include a subroutine, a procedure, or a method. As used herein, the term “communication interface” is intended to embrace any interface for communicating data between two threads, such as via either messaging or remote function call communication. [0007]
  • There are several problems associated with known development and testing systems for embedded devices as described above. First, known testing systems require the use of the embedded device that has an operational RTOS to test the communication interfaces of the threads and to test the execution of the threads themselves. Disadvantageously, known systems do not have the ability to simulate communication interfaces and the corresponding threads that support them. [0008]
  • Second, when using more than one platform to host running threads, there is a compatibility problem representing interfaces on different machines. Different types of machines store messages differently in their respective memory space. Known testing systems do not automatically format data for transmission to different platforms. An example of incompatibility between two computers is when one computer stores a 16-bit integer (2 bytes) with the least significant byte in low memory (Little Endian) and the other computer stores the least significant byte in high memory (Big Endian). When the applications want to exchange this 16-bit integer, the value of the integer is interpreted differently depending on the computer. [0009]
  • Third, known systems require the creation of a custom desktop tool that can communicate with the embedded software. The process of building interface functionality for a specific embedded application is a time consuming and manual process. The desktop tool and the embedded software both require manual updates to their application to enable them to communicate with each other. Thus, there is no seamless and automatic access via a desktop tool to the interfaces for an embedded software application. [0010]
  • Fourth, desktop applications developed in other programming languages that are incompatible with standard C/C++ interface definition files cannot interact with the embedded computer seamlessly. Typically, interface definition files define the format of the messages expected by the embedded software. Languages such as Visual Basic, LabVIEW, etc., cannot use standard C interface definition files that define the format of the interfaces. Thus, software engineers that use these languages cannot test the threads executing on the embedded device. [0011]
  • Thus, there is a need for improved devices for development and testing of embedded software that do not have the foregoing limitations. [0012]
  • SUMMARY OF THE INVENTION
  • One aspect of the invention comprises a system for providing communication between a host computer and an embedded computer. The system comprises an embedded computer executing a plurality of threads that provide a plurality of communication interfaces, each communication interface having a plurality of data fields and a communication database identifying each of the communication interfaces. The communication database is automatically generated, at least in part, from information comprising: an interface description file that defines the communications interfaces; machine characteristics of the embedded device; and machine characteristics of a host platform. The system also comprises a communication module for providing an application programming interface for a COM-compliant application to access the communication interface. The communication module is automatically generated based upon information from the communication database. An object in the COM-compliant application identifies at least one of the communication interfaces in the communication database and invokes a function with respect to at least one data field in the identified communication interface via the application programming interface. The function is selected from the group comprising: storing data in one of the data fields, reading data from one of the data fields, and testing a data field. [0013]
  • Another aspect of the invention comprises a system for providing communication between a host computer and an embedded computer. The system comprises: an embedded computer executing a plurality of threads that each provide a communication interface; a communication database identifying the communication interface of each of the threads; and a COM object configured to provide a plurality of functions to a COM-compliant application for a communicating with each of the communication interfaces, wherein the COM object is automatically generated based, at least in part, upon the communication interfaces in the messaging database. [0014]
  • Another aspect of the invention comprises a method of providing access to a communication, the method comprising: providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and accessing the communication interface via the COM-compliant application. [0015]
  • Yet another aspect of the invention comprises a system for providing access to a communication. The system comprises: means for providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and means for accessing the communication interface via the COM-compliant application. [0016]
  • Yet another aspect of the invention comprises a system for providing a communication interface that is accessible by a plurality of components, the system comprises: a COM-compliant object; at least one thread executing on an embedded computer; and at least one communication module which is configured to provide an application programming interface for the COM-compliant object to communicate with the thread.[0017]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating a development and testing system for testing an embedded computer. [0018]
  • FIG. 2 is a block diagram illustrating certain components of a communication database that is part of the development and testing system of FIG. 1. [0019]
  • FIG. 3 is a block diagram illustrating another embodiment of the development and testing system of FIG. 1. [0020]
  • FIGS. 4A and 4B are a diagram of an exemplary script that can be used to communicate with the embedded computer of FIG. 3. [0021]
  • FIG. 5 is a block diagram illustrating another embodiment of the development and testing system of FIG. 1. [0022]
  • FIG. 6 is a block diagram illustrating the exemplary contents of the communication database of FIG. 1. [0023]
  • FIG. 7 is a block diagram illustrating an exemplary object hierarchy of the generated component of FIG. 5. [0024]
  • FIG. 8 is a flowchart illustrating a process of modifying a source file for use with the development and testing system of FIG. 1. [0025]
  • FIG. 9 is a flowchart illustrating a process of building the communication database of FIG. 1. [0026]
  • FIG. 10 is a flowchart illustrating a process of using the host platform communication module of FIG. 1. [0027]
  • FIG. 11 is a flowchart illustrating a process of formatting a communication. [0028]
  • FIGS. [0029] 12A-12D illustrate exemplary methods of managing pointer data when transmitting the pointer data between two platforms having different machine characteristics.
  • FIG. 13 is a flowchart illustrating a process of using a scripting file to communicate with threads executing on the embedded computer. [0030]
  • FIG. 14 is a flowchart illustrating a process of loading the messaging automation component of FIG. 3. [0031]
  • FIG. 15 is a flowchart illustrating a process of registering a thread executing in a script with the development and testing system of FIG. 3. [0032]
  • FIG. 16A is a flowchart illustrating a process of sending a message communication from a script to the development and testing system of FIG. 3. [0033]
  • FIG. 16B is a flowchart illustrating a process of sending a invoking a function call from a script to the development and testing system of FIG. 3. [0034]
  • FIG. 17A is a flowchart illustrating a process of a script receiving a message via a script from the development and testing system of FIG. 3. [0035]
  • FIG. 17B is a flowchart illustrating a process of a script receiving a communication via remote function call from the development and testing system of FIG. 3. [0036]
  • FIG. 18 is a flowchart illustrating a process of utilizing the generated component of FIG. 5. [0037]
  • FIG. 19 is a flowchart illustrating a process of launching the COM composer of FIG. 5. [0038]
  • FIG. 20 is a flowchart illustrating a process of building the generated component of FIG. 5. [0039]
  • FIG. 21 is a flowchart illustrating a process of generating an interface of the generated component of FIG. 1. [0040]
  • FIG. 22 is a flowchart illustrating a process of using the generated component of FIG. 5 from any COM-compliant language. [0041]
  • FIG. 23 is a flowchart illustrating a process of testing one of the communication interfaces that is identified by the communication database of FIG. 1. [0042]
  • FIG. 24 is a flowchart illustrating a process of generating data sets of information based upon monitoring communications that are transmitted between at least two [0043]
  • FIG. 25 is an exemplary user interface for testing messages. [0044]
  • FIG. 26 is an exemplary user interface for testing remote function calls. [0045]
  • FIG. 27 is a flowchart illustrating a process of generating template code for use with the development and testing system of FIG. 1. [0046]
  • FIG. 28 is a flowchart illustrating a process of generating code for handling a message that is defined by a predefined communication interface. [0047]
  • FIG. 29 is a flowchart illustrating a process of generating message handling code. [0048]
  • FIG. 30 is a flowchart illustrating a process of generating code to send a message to a predefined communication interface. [0049]
  • FIG. 31 is a flowchart illustrating a process of generating code for handling inter-platform messaging in response to a function call. [0050]
  • FIG. 32 is a block diagram illustrating exemplary generated code. [0051]
  • FIG. 33 is a block diagram illustrating exemplary generated code.[0052]
  • DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS OF THE INVENTION
  • The following detailed description is directed to certain specific embodiments of the invention. However, the invention can be embodied in a multitude of different ways as defined and covered by the claims. In this description, reference is made to the drawings wherein like parts are designated with like numerals throughout. [0053]
  • FIG. 1 is a block diagram illustrating one embodiment of a [0054] DAT system 100. The development and testing (“DAT”) system 100 allows developers to have automatic and seamless access to their defined communication interfaces. In addition, the DAT system 100 enables threads to run on distributed platforms, and allows any programming language seamless access to the interfaces.
  • The [0055] DAT system 100 comprises an embedded computer 104 that is in data communication with a host computer 108. The embedded computer 104 executes an embedded computer communication module 112 that is used to route communications to threads 114 executing on the embedded computer 104. The host computer 108 executes a host computer communication module 116 that is used to route messages to threads 120 executing on the host computer 108. The embedded computer communication module 112 and the host computer communication module 116 are able to route to each other messages and/or other communications sent via other interfaces originating from one platform that are destined for transmission to the other platform. In one embodiment of the invention, all communications from one platform to the other platform are transmitted via the embedded computer communication module 112 and the host computer communication module 116.
  • The embedded [0056] computer 104 can reside on a telephone, a card on a peripheral device, an automobile, a refrigerator, or any other electronic device. The host computer 108 can include any computing device that includes a display and an input device, e.g., mouse, keyboard.
  • The [0057] host computer 116 also comprises a communication database 124 that automatically compiles the embedded and host's interface definition files to capture the “characteristics” of a communication interface.
  • The [0058] DAT system 100 provides a standardized API for messaging and tracing, contains a protocol suite used to implement a seamless messaging and tracing environment, and implements the communication link between the two platforms. In one embodiment of the invention, the API that is provided by the DAT system 100 includes interfaces for the following: (i) registering a message; (ii) reading a message; (iii) sending command data; (iv) sending response data; (v) broadcasting a message; (vi) subscribing to a message; (vii) returning the list of messages stored in the communication database; (viii) returning the message format of a specific message; and (ix) returning the name and/or identifier of a specific message. Further exemplary API of the DAT system 100 are described below.
  • A [0059] studio module 128 provides a graphical user interface and testing environment for testing the communication interfaces that are identified by the communication database 124. The DAT system 100 provides complete visibility and control of all the messages and remote function calls defined by an embedded software application. As an example, using the studio module 128, a developer can scan the entire list of messages and/or remote function calls within the database and display them on a screen. Once a specific message or remote function call is selected, the communication database 124 can be queried to return the element types and names associated with the message.
  • Upon execution, each of the threads in the embedded [0060] computer 104 and the host computer 108 register with the DAT system 100. Registration enables the DAT system 100 to dynamically route messages without having to “hardcode” a routing table. Threads at anytime can call a specific application programming interface “API” that is offered by the DAT system 100 to inform the DAT system 100 that the requesting thread “owns” a selected message. Owns, in this context, means that the specific thread receives the message anytime another thread and or application sends it. When a request to send a message is issued, the DAT system 100 determines whether the owning thread is local or on the other platform. If the platform is local, the message is directly routed to the owning thread. If the platform is remote, the message is directly routed to the other platform. If the message originates at the embedded computer 104, upon receipt, the host computer 108 formats the message to be compatible with the machine characteristics of the host computer 108. If the message originates at the host computer 108, the host computer 108 formats the messages to be compatible with the machine characteristics of the embedded computer 104.
  • The embedded [0061] computer communication module 112, the host computer communication module 116, and the studio module 128 each comprise various sub-routines, procedures, definitional statements, and macros. The computer communication module 112, the host computer communication module 116, and the studio module 128 may be written in any programming language such as C, C++, BASIC, Java, Pascal, and Fortran and may be run under the well-known operating system. C, C++, BASIC, Pascal, Java, and Fortran are industry standard programming languages for which many commercial compilers can be used to create executable code.
  • The embedded [0062] computer 104 may execute under the control of any off-the-shelf or proprietary real-time operating system such as: VxWorks, Nucleus, ThreadX, Windows CE, RTXC, and Embedded Linux.
  • The [0063] host computer 108 may execute under the control of any off-the-shelf or proprietary operating system, such as: UNIX, LINUX, Disk Operating System (DOS), OS/2, PalmOS, VxWorks, Windows 3.X, Windows 95, Windows 98, Windows NT, Windows CE, and Windows XP. Each of the threads on embedded computer 104 and the host computer 108 can communication respectively with the embedded computer communication module 112 and the host computer communication module 116 via a predefined application programming interface API. Set forth below are described certain routines provided by the API. It is to be appreciated that other routines may also be provided.
    Application Programming Interfaces
    Owner Methods
    Methods
    Broadcast Broadcasts a response to all subscribed Users.
    (Broadcast message type only)
    Read Command Reads the Command sent by a User (One-way &
    Two-way message types only)
    Register Registers ownership of the service associated with
    the message (One-way & Two-way message types
    only)
    Send Response Sends the response. (Two-way message type only)
    Un-register Un-registers ownership of the service. (One-way &
    Two-way message types only)
    User Methods
    Methods
    Read Response Reads the Response sent from the owner. (Two-way
    and Broadcast message types only)
    Send and Read Combines the Send Command and Read Response
    methods (Two-way message type only)
    Send Command Sends the Command to the registered Owner
    (One-way and Two-way message types only)
    Subscribe Subscribes to the service associated with the
    Message. Once subscribed the Message object will
    receive all broadcasts sent by any owner of the
    service. (Broadcast message type only)
    Un-subscribe Un-subscribes to the service.
    Spy API
    Methods
    Read Command Reads (spies on) a copy of a command sent from a
    User to the Register Owner
    Read Response Reads (spies on) a copy of a Response sent from the
    Owner to the User
    Register Register as a spy of the interface to thereafter
    receive copies of all Commands and Responses sent
    by Owners and Users of the Service.
    Un-register Un-register the object as a spy
    <Dataset methods> Defined below
    Owner Functions API
    Methods
    Register Registers ownership of the service associated with
    the function
    Read Parameter List Reads the Parameter List sent by the Caller
    Return Sends the Return Value to the Caller (User).
    Un-register Un-registers ownership of the function.
    <Dataset methods> Defined below
    User Function API
    Methods
    Call Calls the remote function with the Object's
    Parameter List
    Read Return Value Reads the Return Value returned by the Owner.
    Spy Function API
    Methods
    Read Parameter List Reads (spies on) a copy of the Parameter List sent
    by the Caller
    Read Response Reads (spies on) a copy of the Response sent from
    the Owner to the User
    Register Register the Object as spy of the interface to
    thereafter receive copies of all Calls and Returns
    made between users and owners of the function.
    Un-register Un-register the object as a spy.
    <Dataset methods> Defined below
    Datasets
    Methods
    Clear All Datasets Clears/Deletes all datasets associated with either the
    Command or Response (Messages), or Input or
    Output (Functions)
    Delete Datasets Deletes a specified number of datasets
    Insert Datasets Inserts a specified number of datasets.
    Load Datasets Loads datasets from the database and associates
    them with the interface object.
    Store Datasets Stores the datasets currently associated with the
    interface object into the database.
    Miscellaneous API
    Methods
    Pointer Setup Specify the attributes of a the pointer, e.g., IN,
    IN/OUT, OUT, pooled, private.
    Pointer Attach Invoked each time a pointer address or size is
    modified
  • FIG. 2 presents a functional block diagram of the [0064] communication database 124. The communication database 124 includes a compiler 200 and an access engine 204. The communication database 124 parses standard interface definition files, such as in C, C++, or other programming language, and automatically extracts out the interface and tracing information. The interface definition files contain the formats of the interfaces that are used for thread communication and software tracing. In one embodiment of the invention, a programmer can define these characteristics in the interface definition file via the use of compiler pragmas.
  • The information from the interface definition files is organized and stored in the [0065] communication database 124 such that it that can be accessed by other desktop applications via the host computer communication module 116. An exemplary process of building the communication database 124 is described below with respect to FIG. 9.
  • In one embodiment of the invention, the [0066] DAT system 100 provides seamless and automatic ability for an application on the host computer 108 to make a remote function call to a routine that is on the embedded computer 104 and vice-versa, without requiring modification of the application other than to link the libraries and header files of the DAT system 100. An exemplary process of automatically generating code in support of a remote function call is described below with reference to FIG. 31.
  • FIG. 3 is a block diagram illustrating another exemplary embodiment of the invention. The embodiment of the invention shown in FIG. 3 allows scripting languages to seamlessly access threads that are executing on the embedded [0067] computer 104 and the host computer 108.
  • With respect to the embodiment of the invention shown in FIG. 3, the [0068] DAT system 100 also comprises a messaging automation component (“MAC”) 304 and a script engine 312 for executing a script. In one embodiment of the invention, the MAC 304 is a COM-compliant object that provides interfaces for performing the following functions: designating ownership of an interface, generating a data set, sending a field of information, sending a data set, receiving a message, and listing each of the messages that are managed by the DAT system 100. The script engine 312 can be any proprietary or off-the-shelf engine that supports scripting languages such as: JavaScript, Visual Basic, VBScript, Tcl, JScript, Python, etc.
  • Set forth below is a description of the various objects that are provided by the [0069] MAC 304 for communication. In one embodiment of the invention, there are 6 classes of interface objects: (i) owner message objects; (ii) user message objects; (iii) spy message objects; (iv) owner function objects; (v) user function objects; and (vi) spy function objects. It is to be appreciated that other type of objects may also be used.
  • The application programming interfaces of the [0070] MAC 304 are set forth below.
    Owner Message Object
    Methods
    Broadcast Broadcasts a response to all subscribed Users.
    (Broadcast message type only)
    Read Command Reads the Command sent by a User (One-way &
    Two-way message types only)
    Register Registers ownership of the service associated with
    the message (One-way & Two-way message types
    only)
    Send Response Sends the response. (Two-way message type only)
    Un-register Un-registers ownership of the service. (One-way &
    Two-way message types only)
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    User Message Object
    Methods
    Read Response Reads the Response sent from the owner. (Two-way
    and Broadcast message types only)
    Send and Read Combines the Send Command and Read Response
    methods (Two-way message type only)
    Send Command Sends the Command to the registered Owner
    (One-way and Two-way message types only)
    Subscribe Subscribes to the service associated with the
    Message. Once subscribed the Message object will
    receive all broadcasts sent by any owner of the
    service. (Broadcast message type only)
    Un-subscribe Un-subscribes to the service.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    Spy Message Object
    Methods
    Read Command Reads (spies on) a copy of a command sent from a
    User to the Register Owner
    Read Response Reads (spies on) a copy of a Response sent from the
    Owner to the User
    Register Register as a spy of the interface to thereafter
    receive copies of all Commands and Responses sent
    by Owners and Users of the Service.
    Un-register Un-register the object as a spy
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    Owner Function Object
    Methods
    Register Registers ownership of the service associated with
    the function
    Read Parameter List Reads the Parameter List sent by the Caller
    Return Sends the Return Value to the Caller (User).
    Un-register Un-registers ownership of the function.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    User Function Object
    Methods
    Call Calls the remote function with the Object's
    Parameter List
    Read Return Value Reads the Return Value returned by the Owner.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    Spy Function Object
    Methods
    Read Parameter List Reads (spies on) a copy of the Parameter List sent
    by the Caller
    Read Response Reads (spies on) a copy of the Response sent from
    the Owner to the User
    Register Register the Object as spy of the interface to
    thereafter receive copies of all Calls and Returns
    made between users and owners of the function.
    Un-register Un-register the object as a spy.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    Datasets
    Methods
    Clear All Datasets Clears/Deletes all datasets associated with either the
    Command or Response (Message Objects), or Input
    or Output (Function Objects)
    Delete Datasets Deletes a specified number of datasets
    Insert Datasets Inserts a specified number of datasets.
    Load Datasets Loads datasets from the database and associates
    them with the interface object.
    Store Datasets Stores the datasets currently associated with the
    interface object into the database.
  • In one embodiment, for message objects, datasets are sets of data associated with either the command (command payload) or response (response payload and out pointer data). One-way messages have command datasets, broadcast messages have response datasets, and two-way messages have both. For function objects, datasets are associated with either the input (parameter list) and/or the output (return value and out pointer data). [0071]
  • Scripting languages allow developers to customize, automate testing, and add macro capabilities. Scripting languages, in general, are easy to use for this type of functionality. Scripting languages also contain much of the same capability found in compiled languages such as loops, conditional statements, etc. A script program is text written in a script language that is executed by a script engine. The [0072] messaging automation component 304 provides a script program seamless and instant access to the communication interfaces of each of the threads in the embedded computer 104 and the host computer 108. Using the messaging automation component 304, fields in a message or parameters in a remote function call can be set, read, tested against, or used in expressions. Via the messaging automation component 304, the scripting program can also transmit and receive communications seamlessly with software running on either an embedded computer 104 or the host computer 108. Furthermore, establishing such communication does not require code changes of the threads executing on either the embedded computer 104 and/or the host computer 108.
  • In one embodiment of the invention, the script program is launched via an interface that is provided by the [0073] studio module 128. In another embodiment of the invention, the script program does not have to be launched by the studio module 128, but instead, can be launched and communicate directly with the host computer communication module 116.
  • FIGS. 4A and 4B illustrate exemplary scripts that can execute in the [0074] script engine 312 to communicate with one of the threads 114 that are executing on the embedded computer 104 and/or the host computer 108. Code block 404 illustrates exemplary code that may be used to send a two way message. On line 3 of code block 404, the script sets an object “msg” equal to one of the messages that is maintained in the communication database 124. At line 6, the script sets a field in a payload that is associated with the message. As is known in the art, a payload is structured data. At line 9, the script sends a command message and waits for a response. At line 11, the script retrieves the response data. Code block 408 illustrates exemplary code that may be used to subscribe to a broadcast. Code block 412 illustrates exemplary code that may be used to invoke a function. Code block 416 illustrates exemplary code that may be used to register ownership of a function.
  • FIG. 5 is a block diagram illustrating another embodiment of the invention. A [0075] COM composer 504 automatically builds a generated component 508 that serves as an interface between a COM-compliant application 512 and the host computer communication module 116. COM is a Microsoft technology that enables different applications to communicate with each other using a known interface, independent of the languages that the applications were developed in. For compatibility purposes, COM specifies the particular format and protocol of the interfaces.
  • The generated [0076] component 508 provides the COM-compliant application 512 seamless and instant access to the communication interfaces of an embedded application through predefined API. Using the generated component 508, the COM-compliant application 512 seamlessly communicates with threads executing on the embedded computer 104 and the host computer 108. The host computer communication platform 116 automatically formats communication in a form suitable for its destination. An exemplary process of formatting a communication is described below with reference to FIG. 11.
  • Set forth below is a description of the application programming interfaces that are provided by the generated [0077] component 508.
    Owner Message Object
    Methods
    Broadcast Broadcasts a response to all subscribed Users.
    (Broadcast message type only)
    Read Command Reads the Command sent by a User (One-way &
    Two-way message types only)
    Register Registers ownership of the service associated with
    the message (One-way & Two-way message types
    only)
    Send Response Sends the response. (Two-way message type only)
    Un-register Un-registers ownership of the service. (One-way &
    Two-way message types only)
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    User Message Object
    Methods
    Read Response Reads the Response sent from the owner. (Two-way
    and Broadcast message types only)
    Send and Read Combines the Send Command and Read Response
    methods (Two-way message type only)
    Send Command Sends the Command to the registered Owner
    (One-way and Two-way message types only)
    Subscribe Subscribes to the service associated with the
    Message. Once subscribed the Message object will
    receive all broadcasts sent by any owner of the
    service. (Broadcast message type only)
    Un-subscribe Un-subscribes to the service.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    Spy Message Object
    Methods
    Read Command Reads (spies on) a copy of a command sent from a
    User to the Register Owner
    Read Response Reads (spies on) a copy of a Response sent from
    the Owner to the User
    Register Register as a spy of the interface to thereafter
    receive copies of all Commands and Responses sent
    by Owners and Users of the Service.
    Un-register Un-register the object as a spy
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Command Payload Command payload of the Message Object.
    Response Payload Response payload of the Message Object.
    Out Pointer Data Out pointer data—defined as part of the Command
    payload, populated as apart of the Response.
    <Dataset properties> Defined below
    Owner Function Object
    Methods
    Register Registers ownership of the service associated with
    the function
    Read Parameter List Reads the Parameter List sent by the Caller
    Return Sends the Return Value to the Caller (User).
    Un-register Un-registers ownership of the function.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    User Function Object
    Methods
    Call Calls the remote function with the Object's
    Parameter List
    Read Return Value Reads the Return Value returned by the Owner.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    Spy Function Object
    Methods
    Read Parameter List Reads (spies on) a copy of the Parameter List sent
    by the Caller
    Read Response Reads (spies on) a copy of the Response sent from
    the Owner to the User
    Register Register the Object as spy of the interface to
    thereafter receive copies of all Calls and Returns
    made between users and owners of the function.
    Un-register Un-register the object as a spy.
    <Dataset methods> Defined below
    Properties
    Name Name of the Interface
    SUID STRIDE Unique Identifier for the Interface
    Parameter List List of parameters for the Function Object.
    Return Value Return value for the Function Object.
    Out Pointer Data Out pointer data—defined as part of the Parameter
    List, populated as apart of the Output.
    <Dataset properties> Defined below
    Datasets
    Methods
    Clear All Datasets Clears/Deletes all datasets associated with either the
    Command or Response (Message Objects), or Input
    or Output (Function Objects)
    Delete Datasets Deletes a specified number of datasets
    Insert Datasets Inserts a specified number of datasets.
    Load Datasets Loads datasets from the database and associates
    them with the interface object.
    Store Datasets Stores the datasets currently associated with the
    interface object into the database.
  • It is noted, that in one embodiment, the [0078] MAC 304, the studio module 128, the generated component 508, can be utilized together to provide a communication system for various types of applications. For example, using the application programming interface of the MAC 304, a scripting program in a first language can communicate with a scripting program in the same or a second language, a COM-compliant application 512 via the generated component 508, a thread executing on the embedded computer 104, a thread executing on the host computer 108, and the studio module 128.
  • Furthermore, for example, using the application programming interface of the generated [0079] component 508, a COM-compliant application can communicate with a scripting program via the MAC 304, another COM-compliant application, a thread executing on the embedded computer 104, a thread executing on the host computer 108, and the studio module 128.
  • Furthermore, for example, using the [0080] studio 128, a user can send and receive messages to and from the COM-compliant application 512, a scripting program, a thread executing on the host computer 108, a thread executing on the embedded computer 104.
  • FIG. 6 is a representational block diagram illustrating one embodiment of the [0081] communication database 124. Depending on the embodiment, additional types of information may be added to the database and/or certain types of information may be omitted.
  • The [0082] communication database 124 includes a platform-specific configuration section 604. The platform-specific configuration section 604 contains embedded computer machine characteristics and host computer machine characteristics. The characteristics can include items, such as: an indication of whether the platform is big or little Endian, enumeration sizes, pointer sizes, structure alignment boundaries, etc. It is noted that in one embodiment of the invention, the embedded computer machine characteristics and the host computer machine characteristics are stored in a location other than the communication database 124, such as the host computer communication module 116 or the embedded computer 104.
  • The [0083] communication database 124 also includes a messages section 608 and a prototypes section 610. The messages section 608 and the prototypes section 610 respectively describe the characteristics of each of the messages and remote function calls on the embedded computer 104 and the host computer 108. The characteristics can include: (i) the unique name and or identifier of the message; (ii) the total size of the message; (iii) the type of the communication, e.g., one-way message, two-way message, broadcast message, remote function call; and (iv) the types of data are passed as part of the communication. A one way message is sent from a “user” of the communication to the “owner” of the communication. A thread can request ownership of a message via a registration routine that is provided via an application programming interface of the host computer communication module 116. A two way message comprises a “command” that is sent from the user to the owner and a “response” that is sent from the owner to the user. A broadcast message is sent to all threads that have registered to receive the broadcast.
  • The [0084] communication database 124 also includes a trace points section 612 for maintaining trace points. The communication database 124 also includes a description of the data types that are supported by the messages identified in the messaging section 608 and the functions listed in the prototypes section 610.
  • The [0085] data types section 616 includes: (i) a description of the data types in the data structures that are part of a message or remote function call, e.g., integer, character, Boolean, floating-point, arrays, etc; (ii) the field name of each of the elements in each of the messages; (iii) and a description of characteristics of embedded pointers that may be part of the message.
  • FIG. 7 is a block diagram illustrating an exemplary component hierarchy of the generated [0086] component 508. The COM-compliant object 512 initially accesses the generated component 508 via a root object 704. Via the root object 704, the COM-compliant object 512 can send commands and receive responses from particular messages and remote function calls that are defined in the communication database 124. For example, as is shown in FIG. 7, the COM-compliant object has access to an object 708 that is associated with “MESSAGE 1” and an object 712 that is associated with “MESSAGE 2.” Using predefined interfaces associated with these message objects, the COM-compliant object 512 can send and receive payloads with threads that are executing on the embedded computer 104.
  • FIG. 8 is a flowchart illustrating a process of modifying source code to communicate with the [0087] DAT system 100. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step 804, a programmer adds API calls to invoke a registration method that is provided by the DAT system 100. In one embodiment of the invention, a registering thread provides a unique thread identification code.
  • Next, at a [0088] step 808, the programmer adds API calls to invoke a read method that is provided by the DAT system 100. Continuing to a step 812, the programmer adds, where applicable, API calls to invoke a send method that is provided by the DAT system 100.
  • Continuing to a [0089] state 816, the programmer adds API calls to “subscribe” to a message. Subscribing to a message allows a subscriber to bind to a specific message and thereafter receive all broadcast transmissions. Other messaging APIs may be provided by the DAT system 100 such as for the following: sending a command; sending a response; broadcasting a message; and defining the data (content) and meta-data (characteristics) of the payload of a message.
  • FIG. 9 is a block diagram illustrating an exemplary process of building the [0090] communication database 124. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. In one embodiment of the invention, the process shown in FIG. 9 is performed in response to a user request.
  • Starting at a [0091] state 904, the studio module 128 reads and extracts information from each of a plurality of interface definition files that are provided by the user. Next, at a step 908, the studio module 128 extracts the communication interfaces from each of the interface definition files. Information that is extracted can include: (i) the type of the communication, e.g., one-way, two-way, broadcast, remote function call; (ii) the types of data are passed as part of the communication; (iii) a description of the data types in the data structures that are part of a message or remote function call, e.g., integer, character, Boolean; (iv) a description of characteristics of embedded pointers that may be part of the message, e.g., whether the memory is “pooled” or “private”, a method of transmitting the memory that is associated with the communication interface, and pointer data that is associated with the communication interface.
  • Next at a [0092] step 916, the studio module 128 stores the embedded computer machine characteristics. The embedded computer machine characteristics can be provided by user entry, automatic diagnosis of the embedded computer 104, or automatically provided by the embedded computer 104. Examples of the embedded computer machine characteristics are described above with respect to FIG. 6. In one embodiment, it is assumed that these characteristics are fixed, i.e., exactly the same on each connection.
  • Proceeding to a [0093] step 920, the studio module 128 stores the host computer machine characteristics. The host computer machine characteristics can be provided by user entry or automatic diagnosis of the host computer 108. Examples of the host computer machine characteristics are described above with respect to FIG. 6.
  • FIG. 10 is a flowchart illustrating a process of using the [0094] DAT system 100. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step 1004, the DAT system 100 receives registration information from each thread. Next, at a step 1008, the DAT system receives a payload for a particular message.
  • Continuing to a [0095] step 1012, the DAT system 100 formats the payload for transmission to its destination thread. It is noted that if the destination thread is local to the transmitting thread, then formatting may be unnecessary. An exemplary process of formatting data for transmission to a remote platform is described below with reference to FIG. 11. Moving to a step 1016, the DAT system 100 transmits the formatted payload to the destination thread.
  • FIG. 11 is a flowchart illustrating a process of formatting data for use on an different platform. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. In one embodiment of the invention, the process that is performed by FIG. 11 is performed by the host [0096] computer communication module 116 of the DAT system 100. Furthermore, FIG. 11 is directed to a process of formatting a payload for transmission from one platform, e.g., the host computer 108 to another, e.g., the embedded computer 104.
  • The use of the process shown in FIG. 11 provides interoperability between applications communicating with each other on distributed heterogeneous computing platforms. In one embodiment of the invention, to reduce processing and memory requirements on embedded devices, the [0097] DAT system 100 performs all data formatting on the host computer 108.
  • The [0098] host computer 108 uses the platform characteristics of the embedded computer 104 and the host computer 108 and the individual interface definition information (“the communication interface information”) to properly map messages when two applications on the different computers are communicating. In one embodiment, the embedded computer 104 always sends and receives messages in its native form, i.e., the form in which the message is stored in its memory. The host computer 108 maps these messages into its form when receiving them, and transforms the messages into the embedded computer 104 platform's native form when transmitting the messages to the embedded computer 104.
  • Starting at a [0099] decision state 1104, the host computer communication module 116 determines whether the destination thread is local or remote. If the thread is local, the process proceeds to a step 1108 and the payload is queued for transmission to the destination thread. If the transmission is local, no further modification of the payload is necessary.
  • Referring again to the [0100] decision step 1104, if the destination thread is not local, the process proceeds to a step 1112, wherein the host computer communication module 116 copies data in payload and data referenced by pointers into a message for transmission to the embedded computer 104. An exemplary process of managing pointer data is described in further detail below with reference to FIGS. 12A, 12B, 12C, and 12D.
  • Continuing to a [0101] step 1116, the host computer communication module 116 formats, if necessary, the byte order of the elements in data in the payload. For example, if the host computer 108 is Big Endian, and the embedded computer 104 is Little Endian, or vice-versa, the host computer communication module 116 reverses the order of the bits in the data.
  • Proceeding to a [0102] step 1124, the host computer communication module 116 formats the size of the data types in the payload. For example, if the embedded computer 104 uses a certain bit-length for certain data types and the host computer uses a different bit-length, the host computer communication module 116 adjusts the size of the data for transmission to the other platform. Moving to a step 1128, the host computer communication module 116 adjusts alignment of the data structures according to any requirement of the receiving platform.
  • FIGS. [0103] 12A-12D each illustrate an exemplary method of managing pointers in a payload that are passed from one platform to another. FIG. 12A is directed to a process of receiving a payload from a thread on the embedded computer 104 in connection with a “command” message. In one embodiment, FIG. 12A is performed with respect to each of the pointers in the payload. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. In one embodiment of the invention, the method shown in FIG. 12 is performed by the host computer communication module 116. It is noted that a similar process as shown in FIG. 12 is performed on the embedded computer communication module 112 when the embedded computer communication module 112 receives a command message. However, in one embodiment, for such a process the embedded computer communication module 112 does not perform any of inter-platform formatting of the received data as such formatting is performed by the host computer communication module 116.
  • Before starting at a [0104] state 1204, a thread on the embedded computer 104 has invoked a send command that is part of the application programming interface of the embedded computer communication module 112. In response, the embedded computer communication module 112 has built and then transmitted an inter-platform message to the host computer communication module 116. The inter-platform message includes the payload that was identified as part of the send command and, if applicable, the data that is referenced by the pointers in the payload.
  • Starting at a [0105] step 1204, the host computer communication module 116 gets the embedded pointer attributes of a selected pointer in the payload of the transmitted communication. In one embodiment of the invention, the attribute information is stored in the transmitted communication. A first attribute of each pointer is whether the pointer is classified as “IN”, “OUT”, or “IN/OUT”. The “IN” attribute designates that the data referenced by the pointer is passed from the sender of the command to the owner of the message but no data is to be returned by the owner of the message. The “OUT” attributes designates that the sender of the command will not transmit any data that is referenced by the pointer but data will be returned by the owner and stored in the address referenced by the pointer. The “IN/OUT” attribute indicates that the data that is referenced by the pointer will be sent from the sender of the command and that the owner of the message will return data that is stored in the memory referenced by the pointer.
  • A second attribute of each pointer is whether the pointer is “private” or “pooled.” Management (freeing of the memory when not in use) of “private” memory is handled by the [0106] DAT system 100. Management of “pooled” memory is handled by the user and/or the owner of a message.
  • Continuing to a [0107] step 1210, the host computer communication module 116 creates a local buffer to hold the pointer data. Continuing to a decision step 1212, the host computer communication module 116 determines whether the pointer attribute is either “IN” or “IN/OUT”. If the pointer attribute is “IN” or “IN/OUT”, the process proceeds to a step 1214. Continuing to a step 1214, the host computer communication module 116 copies the pointer data that was transmitted from the embedded computer 104 into the local buffer. At this step, the host computer communication module 116 formats the pointer data in accordance with the process described above with reference to steps 1116, 1124, and 1128.
  • Next, at a [0108] step 1218, the host computer communication module 116 copies the address of the buffer into the payload. Proceeding to a decision step 1220, the host computer communication module 116 determines whether the first attribute of the pointer is “IN”. If the first attribute of the pointer is “IN” the process proceeds to a decision step 1222. At the decision step 1222, the host computer communication module 116 determines whether the second attribute of the pointer is “private”. If the second attribute of the pointer is private, the process proceeds to a step 1228. Otherwise if the second attribute of the pointer is not private, i.e., pooled, the process ends.
  • Referring again to the [0109] decision step 1212, if the first attribute is not “IN” or “IN/OUT”, the attribute is the “OUT” and the process proceeds to a step 1216. At the step 1216, the host computer communication module 116 copies the address of the local buffer into the payload. From step 1216, or from decision step 1220 (if the first attribute is “IN/OUT”), the process proceeds to a step 1224. At this step, the host computer communication module 116 waits for thread on the host computer 108 to invoke a response command that is provided by the application programming interface of the DAT system 100. Upon receiving the response, the process proceeds to a step 1226. At this step, the response data is formatted for transmission to the embedded computer 104.
  • From either [0110] step 1226 or from the decision step 1222 (if the second attribute of the pointer is “private”), the process proceeds to a step 1228 wherein the host computer communication module 116 waits for a thread on the host computer 104 to invoke a read complete command that is in the application programming interface of the host computer communication module 116. Upon receipt of the read complete command, the process proceeds to a step 1230 wherein the host computer communication module frees the memory.
  • FIG. 12B is directed to a process of managing pointers in a payload in a command message that is sent from a thread on the [0111] host computer 108 to a thread on embedded computer 104. FIG. 12B illustrates in further detail the steps that occur in step 111 of FIG. 11. In one embodiment, FIG. 12B is performed with resect to each of the pointers in the payload. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. A similar process is performed by the embedded computer when transmitting a command message from a thread on the embedded computer 104 to the host computer 108. However, in this process, the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • Starting at a [0112] step 1230, the host computer communication module 116 creates a buffer to hold an inter-platform message for transmission to the embedded computer 104. Also, at this step, the host computer communication module 116 creates a header in the inter-platform message for the embedded pointer. Furthermore, at this step, the host computer communication module 116 stores the pointer attributes of the pointer in the inter-platform message.
  • Continuing to a [0113] decision step 1232, the host computer communication module 116 determines whether the pointer attribute of the pointer is “OUT”. If the attributes of a selected pointer is “OUT”, the process ends. However, if the pointer attribute is not “OUT”, i.e., it is “IN” or “IN/OUT”, the process proceeds to step 1244. At the step 1244, host computer communication module 116 copies the data referenced by the pointer into the header. Furthermore, the host computer communication module 116 formats the data for use by a thread on the embedded computer 108. For example, the host computer communication module performs the steps described above with respect to steps 1116, 1124, and 1128.
  • Next, at a [0114] decision step 1236, the host computer communication module 116 determines whether the pointer attributes is “IN.” If the pointer attribute is “IN”, the process proceeds to a step 1240. At this step, the host computer communication module 116 frees the memory, if warranted, i.e., the attributes of the pointer designate “pool”. However, if the pointer attribute is not “IN”, the proceeds ends.
  • FIG. 12C is directed to a process of receiving a response message from the embedded [0115] computer communication module 112. FIG. 12C illustrates in further detail the steps that occur in step 111 of FIG. 11. In one embodiment, FIG. 12C is performed with resect to each of the pointers in the payload. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. A similar process is performed by the embedded computer 104 when transmitting a command message from a thread on the embedded computer 104 to the host computer 108. However, in this process, the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • Before starting at a [0116] state 1250, a thread on the embedded computer 104 has invoked a send response command that is part of the application programming interface of the embedded computer communication module 112. In response, the embedded computer communication module 112 has built and then transmitted an inter-platform message to the host computer communication module 116. The inter-platform message includes the payload that was identified as part of the send response and, if applicable, the data that is referenced by the pointers in the payload.
  • Starting at a [0117] decision step 1250, the host computer communication module 116 determines whether the pointer attributes of the pointer in the inter-platform message designate the attribute “IN”. If the pointer attributes designate the attribute “IN”, the process proceeds to a step 1252, and the host computer communication module 116 formats the received data for use with the host computer 108. For example, in one embodiment, the host computer communication module 116 performs the steps described above with respect to steps 1116, 1124, and 1128.
  • However, if the pointer attributes do not designate “IN”, i.e., the pointer attributes designate “IN/OUT” or “OUT”, the process proceeds to a [0118] step 1254. At the step 1254, the host computer communication module 116 creates a local buffer to store the pointer data that was transmitted by the embedded computer 104. Continuing to a step 1256, the host computer communication module 116 copies the pointer data from the inter-platform communication into the local buffer. Next, at step 1258, the host computer communication module 116 copies the address of the buffer into the received payload.
  • Proceeding to a [0119] decision step 1260, the host computer communication module 116 determines whether it should free the pointer. In one embodiment of the invention, this is determined by reading the pointer attributes. If the pointer attributes designate “private” the host computer communication module 116 decides to free the memory. However, if the pointer attributes designate “pooled” the host computer communication module 116 allows the user to free the memory.
  • If the host [0120] computer communication module 116 determines in step 1260 to free the memory, the process proceeds to a step 1262, wherein the host computer communication module 116 waits for a thread on the host computer 108 to invoke the read complete command. Continuing to a step 1264, the host computer communication module 116 frees the local buffer. From either decision step 160 (if the host computer communication module 116 does not free the pointer) or the step 1264 the process ends.
  • FIG. 12D is directed to an exemplary process of managing pointers in a payload in a response message that is sent from a thread on the [0121] host computer 108 to a thread on embedded computer 104. FIG. 12D illustrates in further detail the steps that occur in step 1112 of FIG. 11. In one embodiment, FIG. 12D is performed with resect to each of the pointers in the payload. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. A similar process is performed by the embedded computer 104 when transmitting a response message from a thread on the embedded computer 104 to the host computer. However, in this process, the embedded computer communication module 112 does not perform any formatting of the transmitted payload since the formatting is performed by the host computer communication module 116 upon receipt of the payload.
  • Before starting, a thread on the embedded [0122] computer 104 has sent a command message and a thread on the host computer 108 has responded by invoking the send response routine of API of the DAT system 100.
  • Starting at a [0123] step 1265, the host computer communication module 116 allocates space in an outgoing buffer (“a header”) to store the data that is referenced by the pointer. The outgoing buffer is part of an inter-platform message that is sent from the host computer communication module 116 to the embedded computer communication module 112. Proceeding to a decision step 1266, the host computer communication module 116 determines whether the pointer attributes designate “IN”. If the pointer attributes do designate “IN”, i.e., they do not designate “OUT” or “IN/OUT”, the process proceeds to a decision step 1267. At the decision step 1267, the host computer communication module 116 determines whether to free memory that is associated with the memory that was allocated during the corresponding send command. In one embodiment of the invention, this is determined by reading the pointer attributes. If the pointer attributes designate “pool” the host computer communication module 116 decides to free the memory. However, if the pointer attributes designate “private” the host computer communication module 116 allows the user to own and eventually free the memory (via an routine provided by the local operating system). If the host computer communication module 116 determines it should free the memory, the process proceeds to a step 1268, and the host computer communication module 116 frees the memory. From either step 1268 or decision step 1266 (if the pointer attributes does not designate “IN”), the process proceeds to a step 1270 and the host computer communication module 116 formats the data referenced by the pointer for transmission to the embedded computer. For example, in one embodiment, the host computer communication module 116 performs the steps described above with respect to steps 1116, 1124, and 1128. As part of the formatting, the formatted data is stored in the header (step 1265).
  • FIG. 13 is flowchart illustrating a process of using the [0124] DAT system 100 from a script in the script engine 312. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step 1304, the studio module 128 has received a request from a user to load a script file and it does so here. Next, at a step 1312, studio determines script type that is associated with the script file. The script type can be determined in different ways, including examining the extension of the identified script file or from the contents of the script itself. Exemplary types of scripting languages include: JavaScript, Visual Basic, VBScript, Tcl, JScript, Python, etc.
  • Moving to a [0125] step 1316, the studio module 128 identifies the corresponding script engine 312 that is associated with the script type. Continuing to a step 1320, the studio module 128 initializes the script engine 312.
  • Next, at a [0126] step 1324, the studio module 128 loads the messaging automation component (“MAC”) 304. The process of loading the MAC 304 is described below with reference to FIG. 14. Proceeding to a step 1328, the MAC 304 is “exposed” to the script engine 312. In one embodiment of the invention, exposing the MAC 304 includes providing the script engine 312 a handle to the MAC 304. Next, at a step 1332, the script engine is launched, allowing the script loaded in a step 1304 to access the API of MAC 304. Moving to a step 1336, a script program can communicate with threads 114 using the API of the MAC 304. An exemplary process of using the MAC 304 is described below with respect to FIG. 15.
  • FIG. 14 is a flowchart illustrating a process of loading the [0127] MAC 304. FIG. 14 illustrates in further detail the steps that occur in step 1324 of FIG. 13. Starting at a step 1404, the studio module 128 calls the initialization routine of the MAC 304 and passes as a parameter a handle to the communication database 124. Next, at a step 1408, the MAC 304 generates a messaging automation component “MAC” database object. The MAC database object contains certain of the information from the communication database 114. The MAC database is used by the scripting program to access application programming interfaces of the MAC 304.
  • FIGS. [0128] 15-17 are flowcharts illustrating a process of communicating with the MAC 308 using a scripting language. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. FIG. 15 is a flowchart directed to a process of registering a particular message with the MAC 304. Starting at a step 1504, a script that is executing in the scripting engine 312 invokes a register method of the MAC 304. Proceeding to a step 1508, the MAC object calls the register API of the host computer communication module 116.
  • FIG. 16A is a flowchart illustrating a process of sending a message via the [0129] MAC 304. Starting at a step 1604, the script retrieves reference to a MAC database object. Next, at a step 1606, the script requests the MAC database object to provide a reference to a message object. The message object is used by the script program to communicate with a owner of a communications or to receive communications from others. Using the message object, a script can set fields of the message, send a message, receive a message, and perform other standard messaging functions.
  • Continuing to a [0130] step 1610, the MAC database object retrieves the message definition information from the communication database 124. In one embodiment of the invention, the message definition information is retrieved via the host computer communication module 116. In another embodiment of the invention, the message definition information is retrieved directly from the communication database 124. The message definition information includes: (i) the type of the communication, e.g., one-way, two-way, broadcast, remote function call and (ii) the types of data that are passed as part of the communication. Next, at a step 1614, the MAC database object creates a MAC message object based upon the prototype definition retrieved from the communication database 124.
  • Proceeding to a [0131] step 1618, the MAC database object retrieves any data sets from the communication database that are stored with respect to the requested message object. Next, at a step 1622, the MAC database object adds the data sets to the message object (created in step 1614).
  • Moving to a [0132] step 1624, the MAC database object returns a reference to the message object to the script. Next, at a step 1628 the script can set the data fields of the message using reference to the message object. The script has access via the MAC database object to a plurality of readable and writeable data sets. At this step, the script can identify one of the data sets for subsequent usage. Continuing to a step 1632, the script invokes a send method of the method object. Proceeding to a step 1636, the MAC database object sends a data set that is referenced by the current index to the thread that owns the message.
  • Next, at a [0133] decision step 1640, the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1644, and the MAC database object selects the next data set. Referring again to the decision step 1640, if auto-increment is not enabled, the process ends.
  • FIG. 16B is a flowchart illustrating a process of invoking a function via the [0134] MAC 304. Starting at a step 1650, the script retrieves reference to the MAC database object. Next, at a step 1654, the script requests the MAC database object to provide a reference to a remote function call object. The remote function call object is used by the script program to communicate with the thread that handles the remote function call. Using the remote function call object, a script can set the parameters that will be passed upon invoking the remote function call.
  • Continuing to a [0135] step 1658, the MAC database object retrieves the remote function call prototype definition information from the communication database 124. In one embodiment of the invention, the prototype definition information is retrieved via the host computer communication module 116. In another embodiment of the invention, the message definition information is retrieved directly from the communication database 124.
  • Next, at a [0136] step 1662, the MAC database object creates a MAC remote function call object based upon the remote function call prototype definition retrieved from the communication database 124.
  • Proceeding to a [0137] step 1664, the MAC database object retrieves any data sets from the communication database that are stored with respect to the requested remote function call object. Next, at a step 1666, the MAC database object adds the data sets to the MAC remote function call object.
  • Moving to a [0138] step 1668, the MAC database object returns a reference to the remote function call object to the script. Next, at a step 1670, the script can set the data fields (parameters) of the remote function call using the remote function call object. The script has access via the MAC database object to a plurality of readable and writeable data sets. At this step, the script can identify one of the data sets for subsequent usage. Continuing to a step 1672, the script invokes a call method of the remote function call object. Proceeding to a step 1674, the MAC database object sends a data set that is referenced by the current index to the thread that handles the remote function call.
  • Next, at a [0139] decision step 1676, the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1678, and the MAC database object selects the next data set. Referring again to the decision step 1676, if auto-increment is not enabled, the process ends.
  • FIG. 17A is a flowchart illustrating a process of a script receiving a message via the [0140] MAC 304. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Starting at a [0141] step 1700, the script calls a read method of the MAC database object. Next, at a step 1704, the MAC database object calls a read API of the host computer communication module 116. Continuing to a step 1708, the host computer communication module 116 waits for a message to be received. Proceeding to a step 1712, the MAC database object receives the message and a message identifier from the host computer communication module 116. Next, at a step 1720, the MAC database object returns a message object to the script, which can in turn access the contents of the requested message.
  • FIG. 17B is a flowchart illustrating a process of a script receiving a communication via function call application programming interfaces that are provided by the [0142] MAC 304. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step 1750, the script calls a read method of the MAC database object. Next, at a step 1754, the MAC database object calls the read API of the host computer communication module 116.
  • Continuing to a [0143] step 1758, the MAC database object waits for a remote function call command message to be received. Next, at a step 1762, the MAC database object receives the remote function command message and the function identifier.
  • Proceeding to a [0144] step 1764, a remote function call object is returned to the script program. Next, at a step 1766, the script program access the input parameters of the remote function call object.
  • Moving to a [0145] step 1768, the MAC database object returns a reference to the remote function call object to the script. Next, at a step 1770, the script invokes a return method of the remote function call object. Continuing to a step 1772, the remote function call object calls the send application programming interface of the host computer communication module 116. Proceeding to a step 1774, the MAC database object sends a data set that is referenced by the current index to the thread that handles the remote function call.
  • Next, at a [0146] decision step 1776, the MAC database object determines whether auto-increment is enabled. Auto-increment enables a script to send different data sets with each send command. If auto-increment is enabled, the process proceeds to a step 1778, and the MAC database object selects the next data set. Referring again to the decision step 1776, if auto-increment is not enabled, the process ends.
  • FIG. 18 is a flowchart illustrating a process of interfacing with the [0147] DAT system 100 from any COM-compliant language. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step 1804, a user loads “launches” the COM composer tool 504 (FIG. 5). An exemplary process of loading the COM composer tool is described below with reference to FIG. 19.
  • Next, at a [0148] step 1808, the COM composer builds the generated component 508 (FIG. 5). The generated component 508 is a COM object that is accessible by other COM compliant programs. Using the generated component 508, a COM-compliant program can easily: test a interface, send a communication to a thread that is executing on the embedded computer 104 or the host computer 108, receive a communication that is sent from a thread this executing on the embedded computer or the host computer 108, and other functions as described herein. The generated component 508 provides a plurality of predefined interfaces for performing each of the foregoing functions. An exemplary process of building the generated component 508 is described below with reference to FIG. 20.
  • Continuing to a [0149] step 1816, the generated component 508 is accessible via any COM-compliant language. An exemplary process of using the generated component is described below with reference to FIG. 22.
  • FIG. 19 is a flowchart illustrating an exemplary process of launching the [0150] COM composer tool 504. FIG. 19 illustrates in further detail certain steps that occur in step 1804 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Starting at a [0151] step 1904, a user identifies a database. The DAT system 100 can support multiple databases for multiple projects. Continuing to a step 1908, the user selects which messages or functions of the selected database are to be included in the generated COM object. In one embodiment of the invention, the user selects the messages and/or remote function calls via a graphical user interface utility.
  • Proceeding to a [0152] step 1912, the user selects the compiler version. The COM composer 504 needs to know the version of the compiler that is being used to build the generated component 508 to provide the proper control files in the proper format. Moving to a step 1916, the COM composer 504 requests the user to designate the type of build, e.g., release or debug.
  • FIG. 20 is a flowchart illustrating an exemplary process of building the generated [0153] component 508. FIG. 20 illustrates in further detail certain steps that occur in step 1808 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Starting at a [0154] step 2004, the COM composer tool loads the data that was identified by the user (step 1904) into memory. Next, at a step 2008, the COM composer tool begins a process that is performed with respect to the following: (i) all of the messages and/or remote function calls identified by the user (step 1908), (ii) all of the payloads of the identified messages and/or remote function calls, and (iii) the root object that is used to access all other objects in the generated component 508. In one embodiment, steps 2012, 2016, 2020, and 2024 are performed for each of the foregoing objects.
  • At the [0155] step 2012, the COM composer 504 generates a software interface for each of the objects. An exemplary process of generating an interface is described below with reference to FIG. 21. Next, at a step 2016, the generated component generates a COM class definition for the object, otherwise known as a co-class. Proceeding to a step 2020, the COM composer generates a COM class implementation for each of the COM objects. For further information regarding generating software interfaces, COM class definitions, and a COM class implementations, please see the following references, which are each incorporated by reference in their entirety: DON BOX, ESSENTIAL COM (1998), and BRENT RECTOR, CHRIS SELLS & JIM SPRINGFIELD, ATL INTERNALS (1999).
  • Moving to a [0156] decision step 2024, the COM composer 504 determines whether it has processed all of the messages/remote function calls, payloads, and the root object. If all of these items have not been processed, the process returns to the step 2012 (discussed above). However, if all of the items have been processed, the COM composer 504 proceeds to a step 2028 and provides any compiler specific files that are needed, if any.
  • Next, at a [0157] step 2032, the COM composer 504 launches the selected compiler to build the generated component 508. In one embodiment of the invention, the COM component is provided in a dynamic link library “.DLL”. Moving to a step 2036, the COM composer 504 registers the dynamic link library with a registry in the host computer 108.
  • FIG. 21 is a flowchart illustrating a process of generating an interface. FIG. 21 illustrates in further detail the steps that occur in [0158] step 2012 of FIG. 20. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Starting at a [0159] step 2104, the COM composer 504 generates method definitions for “built-in” member functions. Next, at a step 2108, the COM composer 504 generates accessor function for child objects 2108. For example, the children of the root object includes each of the messages and/or remote function calls. Furthermore, for example, the children of a message object and/or a remote function call object includes one or more payloads that are associated with the object. Moving to a step 2112, the COM composer 504 generates interface for setting and getting properties of objects.
  • FIG. 22 is a flowchart illustrating a process of using the generated [0160] component 508. FIG. 22 illustrates in further detail certain steps that occur in step 1816 of FIG. 18. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Before starting at a [0161] step 2216, the user has opened a COM development environment and located the via the COM development environment the generated component 508.
  • Starting at the [0162] step 2216, the user creates a reference to the generated component 508. Next, at a step 2220, the user creates an instance of the root object. Moving to a step 2224, the user can use the root object accessor function to retrieve a desired message object or remote function call object. Continuing to a step 2228, the user can use the accessor function of the object to select a desired payload object.
  • Proceeding to a [0163] step 2232, the user invokes a method of the payload object to get or set properties of the payload object. For, example, the user can store data in the payload object. Next, at a step 2236, the user invokes methods on the message object or the remote function call object to send a communication. The user may also invoke other methods on a message object such as register the message such any broadcast on the message is received by the invoking process. Other methods are described above with reference to FIG. 5. Next, at a step 2240, the user implements an event handler to receive asynchronous communications that are received, if any.
  • FIG. 23 is a flowchart illustrating a process of using the [0164] studio module 128. The studio module 128 provides a graphical user interface control panel for testing each of the communication interfaces that are identified by the communication database 124. Starting at a step 2304, a user loads a selected communication database 124. A user may have different communication databases for different projects. Once loaded, a user may view and select any of the communication interfaces in the communication database 124. After a is selected, the user can perform a number of functions with respect to the database such as: designating ownership of a communication interface (step 2312), generating a data set (state 2316), sending a field of information (step 2320), and sending a data set (step 2324).
  • FIG. 24 is a flowchart illustrating a process of generating a data set based upon monitoring the communication between two threads executing under the [0165] DAT system 100. It is noted that the process of generating a data set can be initiated by a user either: (i) the studio module 128, (ii) C language source code that invokes a method of the host computer communication module 116, (iii) a script executing in the script engine 312, or (iv) a COM-compliant application via the generated component 508.
  • Starting at a [0166] step 2404, the user specifies the communication data paths that are to be traced. For example, the DAT system 100 can trace that data is sent via a message or via a remote function call.
  • Next, at a [0167] step 2408, the DAT system 100 monitors and stores the data that is transmitted across each of the designated communication paths. In one embodiment of the invention, the data is stored in a persistent test data object. Proceeding to a step 2412, any thread can then select and retrieve the contents of any of persistent test data objects and use the data for testing. Continuing to a step 2416, one of the threads of the DAT system 100 uses one of the persistent data object to transmit data from one of the selected persistent data object across one of the communication data paths.
  • FIG. 25 illustrates an [0168] exemplary user interface 2500 that is provided by the studio module 128. The user interface 2500 includes an interface window 2504 that lists all of the interfaces that are maintained in the communication database 124. Each entry in the in the interface list is selectable by a user. In response to user selection, a communication window 2508 is displayed on the screen. The communication window 2508 includes an register icon 2510 that allows a user to register ownership of a message or remote function call. In one embodiment, if a message is a two-way message, the communication window is divided into a command window 2508 and a response window 2510. The command window and the response window include one or more data set fields 2512. The number of data set fields is configurable by the user. The data sets show the contents of the most recent payload and a user configurable number of previously received payloads.
  • Using the [0169] data set fields 2512, the user can build a payload for a particular command message and set the payload of the response message. Furthermore, the user can select a “store data set” icon 2514 to store the values in the data set fields 2512 in the communication database 124. Later, the user can select a “load data set” icon 2516 to load the stored values. Furthermore, the user may select a clock icon 2518 to have the studio module 128 automatically iterate and transmit the data values in sequence at a user configurable time interval.
  • FIG. 26 illustrates an [0170] exemplary user interface 2600 that allows a user to view and test the parameters that are transmitted as part of a function call. Using a register icon, a user can register ownership of a function. A user window 2608 displays a plurality of parameter fields 2610 that allow a user to set the values of parameters in the function. An owner window 2610 displays the parameters that have been passed to the function. The user interface 2600 allows the saving and loading of data sets as described above with reference to FIG. 25.
  • FIG. 27 is a flowchart illustrating a process of automatically generating templates of source code for use with the embedded [0171] computer communication module 112 or the host computer communication module 116. In one embodiment of the invention, the process of FIG. 27 is performed by the studio module 128. In another embodiment of the invention, the process of FIG. 37 is performed by a standalone tool, such as a code generator. For convenience of description, the following description refers to a code generator. However, it is to be appreciated that such function could be provided by the studio module 128 or the communication database 124. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Starting at a [0172] step 2704, the user identifies one or more interface definition files that define the communication interface. For example, in code block 3200 of FIG. 32 illustrates a portion of an interface definition file.
  • Continuing to a [0173] step 2708, the user selects one or more of the communication interfaces in the selected interface definition files. In one embodiment of the invention, a code generator provides a graphical user interface utility for selection of the communication interfaces.
  • Next, at a [0174] step 2716, a code template of a “thread” is generated for handling each of selected messages in the interface definition file. An exemplary process of generating a thread is described below with reference to FIG. 28. An exemplary template is shown in code block 3204 of FIG. 32.
  • Moving to a [0175] step 2720, a template of a thread is generated for each of the selected functions in the interface definition file. An exemplary process of generating a thread is described below with reference to FIG. 31. An exemplary template is shown in code block 3204 of FIG. 32.
  • FIG. 28 is a flowchart illustrating a process of generating a thread for each of the identified messages in an interface definition file. FIG. 28 illustrates in further detail the steps that occur in [0176] step 2716 of FIG. 27. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged.
  • Before starting at a [0177] step 2800, a message handling routine is created to handle all messages that have been identified by the user. The message handling routine includes a loop and, subsequent to the loop, a switch statement. See e.g., code block 3204. Starting at a step 2800, a loop is entered and steps 2804, 2808, and 2812 are performed for each of the identified messages. Continuing to a step 2804, the code generator adds a line of code to register each of the messages. See e.g., code block 3204. In one embodiment of the invention, the source code includes code to invoke a registration routine that is provided by the embedded computer communication module 112 or the host computer communication module 116. The call to invoke the registration route is placed prior to the generated switch statement.
  • Next, at a [0178] step 2808, the code generator generates message handling code for each of identified messages. An exemplary process of generating message handling code is described below with reference to FIG. 29. Continuing to a step 2812, the code generator creates routines for sending a message. An exemplary process of creating a routing for sending a message is described below with reference to FIG. 30.
  • FIG. 29 is a flowchart illustrating a process of generating message handling code. FIG. 29 illustrates in further detail the steps that occur in [0179] step 2908 of FIG. 28. Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. The process shown in FIG. 29 is performed with respect to each of the messages identified by the user in step 2708 of FIG. 27.
  • Starting at a [0180] step 2904, the code generator generates a case statement. Proceeding to a step 2908, the code generator generates a comment to the user to instruct the user to add code.
  • Proceeding to a [0181] decision step 2912, the code generator determines whether the message is “two-way”. If the message is “two-way”, the process proceeds to a step 2916. Otherwise, the process proceeds to a step 2920.
  • At the [0182] step 2916, the code generator adds code in the generated case statement to invoke a send response routine. As an example, code block 3204 of FIG. 32 includes a call to the “SendMesessageTwoWayResponse” routine. The process of generating a response routine, such as the “SendMesessageTwoWayResponse” routine, is described below with reference to 3016 of FIG. 30. In one embodiment of the invention, the generated code will invoke an API, e.g., SendResponse(), of the DAT system 100. At this step, the code generator may also generate other APIs for convenience of the user, e.g., routines to setup and attach pointers. Moving to a step 2920, the code generator may also generate code to invoke a release routine that is provided by the API.
  • FIG. 30 is a flowchart illustrating a process of generating a template of a routine for sending a message via the communication interface identified by the user in [0183] step 2708 of FIG. 27. FIG. 30 illustrates in further detail the steps that occur in step 2812 of FIG. 28. Starting at a step 3008, the code generator determines whether the message is one-way, two-way, or broadcast. If the message is one-way or two-way, the process proceeds to a step 3010. At the step 3010, the code generator generates a function to send a command to invoke a send command. An exemplary generated code template is shown in code block 3208 of FIG. 32. Continuing to a decision step 3012, the code generator determines whether the communication is one-way or two-way. If the message is not one-way, i.e., two-way, the process proceeds to a step 3016. At the step 3016, the code generates a function for sending a response. The generated code invokes the API to send a response.
  • Referring again to the [0184] decision step 3008, the code generator determines whether message is a broadcast message. If the message is a broadcast, the process proceeds to a step 3020. At the step 3020, the code generator adds code to invoke an broadcast routine that is part of the API of the embedded computer communication module 112 and the host computer communication module 116. From steps 3012 (if the communication is “one-way”), 3020, and 3016 the process proceeds to a step 3024. At the step 3024, the code generator determines whether there are pointers present in the payload of the message. If pointers are present, the process proceeds to a step 3028. At the step 3028, the code generator generates code to invoke a pointer setup command that is part of the communication library API. Next, at a step 3032, the code generator generates code to invoke the API attach pointer. It is noted that the generated commands during steps 3032 and 3028 are inserted into the generated code prior to the generated send response command (step 3016).
  • FIG. 31 is a flowchart illustrating a process of generating template code for communicating across platforms via a remote function call. In one embodiment of the invention, inter-platform function calls invoke a local function that communicates with the remote function of the same name via messaging that is provided by the embedded [0185] computer communication module 112 and the host computer communication module 116.
  • Depending on the embodiment, additional steps may be added, others removed, and the ordering of the steps rearranged. Starting at a step [0186] 3104 a loop is performed with respect to steps 3108, 3112, and 3116. In the loop, template code is generated for exestuation on a local platform, i.e., either the embedded computer 104 or the host computer 108. The local platform in this context is defined to be the computer that does not have the routine that is to be invoked. Steps 3108, 3112, and 3116 are performed with respect to each of the functions identified by the user in step 2708 of FIG. 27. At the step 3108, the code generator generates a send command. Next, at a step 3112, the code generated generates a read command. Proceeding to a step 3116, the code generator generates code to return a response. An exemplary code block resulting from steps 3108, 3112, and 3116 is shown in code block 3212 of FIG. 33.
  • Next, at a [0187] step 3120, a loop is performed with respect to steps 3124, 3128, 3132, 3136, and 3140. In this loop, template code is generated for execution on the remote platform. Proceeding to a step 3124, the code generator generates code to invoke a registration routine of the API. Moving to a step 3128, the code generator generates code that invokes the local API that was requested by the thread on the other platform and sends a response message. An exemplary code block resulting from steps 3124, 3218, 31332, 3136, and 3140 is shown in code block 3214.
  • Next, at a [0188] decision step 3132, the code generator determines whether there are any pointers in the parameters of the function. If there are no pointers in the parameters of the function, the process ends. However, if there are pointers, the process proceeds to a step 3136 and the code generator generates code to invoke the API to setup a pointer. Moving to a step 3140, the code generator generates code to invoke the API to attach a pointer. The process then ends.
  • The [0189] DAT system 100 provides a single virtual environment that enables threads to be located on different platforms and still seamlessly communicate with each other. The DAT system 100 provides communication interoperability between the two platforms by automatically transforming the data depending on the machine characteristics of the embedded computer 104, the host computer 108, and the communication interfaces that are stored in the communication database 124. The DAT system 100 provides automatic and seamless access to the message-based and remote function call interfaces designed into the embedded computer's software application. The DAT system 100 automatically extracts interface information and builds a database of messaging and remote function call information.
  • Using the [0190] studio module 128, a user has complete visibility and control of the embedded application's interfaces without having to address the following issues: (i) updates to a desktop tool to accommodate new messages; (ii) updates to the embedded software to support the desktop tool's new functionality; (iii) what target compiler is used; (iv) what RTOS is used; and (iv) what platform the thread(s) are executing on. The DAT system 100 allows seamless access to interfaces stored in the communication database 124 via scripting languages or any COM-compliant application.
  • While the above detailed description has shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the spirit of the invention. The scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. [0191]

Claims (25)

We claim:
1. A system for providing communication between a host computer and an embedded computer, the system comprising:
an embedded computer executing a plurality of threads that provide a plurality of communication interfaces, each communication interface having a plurality of data fields;
a communication database identifying each of the communication interfaces, wherein the communication database is automatically generated, at least in part, from information comprising:
an interface description file that defines the communications interfaces;
machine characteristics of the embedded device;
machine characteristics of a host platform; and
a communication module for providing an application programming interface for a COM-compliant application to access the communication interface, wherein the communication module is automatically generated based upon information from the communication database;
wherein an object in the COM-compliant application identifies at least one of the communication interfaces in the communication database and invokes a function with respect to at least one data field in the identified communication interface via the application programming interface, wherein the function is selected from the group comprising: storing data in one of the data fields, reading data from one of the data fields, and testing a data field.
2. The system of claim 1, wherein the communication interface is either a message-based or a remote function call-based interface.
3. A system for providing communication between a host computer and an embedded computer, the system comprising:
an embedded computer executing a plurality of threads that each provide a communication interface;
a communication database identifying the communication interface of each of the threads; and
a COM object configured to provide a plurality of functions to a COM-compliant application for a communicating with each of the communication interfaces, wherein the COM object is automatically generated based, at least in part, upon the communication interfaces in the messaging database.
4. The system of claim 3, wherein the messaging database is generated, at least in part, from information from an interface description file.
5. A system for providing communication between a host computer and an embedded computer, the system comprising:
a plurality of threads that each provide a communication interface;
a communication database identifying each of the communication interfaces; and
a COM object providing a plurality of functions for communicating with each of the communication interfaces, wherein the COM object is automatically generated based, at least in part, upon communication interfaces in the communication database.
6. The system of claim 5, wherein the communication database is generated, at least in part, from information from an interface description file.
7. A method of providing communication with a thread, the method comprising:
retrieving a reference to a communication object, wherein the communication object provides an interface for a COM-compliant application to access a communication interface that is owned by a thread that is executing on an embedded computer; and
storing data in at least one data field in the communication interface.
8. The method of claim 7, additionally comprising invoking a send method of the communication object thereby transmitting the stored data to the thread that is executing on the embedded computer.
9. A method of providing communication with a thread, the method comprising:
retrieving a reference to a communication object, wherein the communication object provides an interface for COM-compliant application to access a communication; and
invoking a read method of the communication object thereby receiving via the interface a communication that is provided by a thread that is executing on an embedded computer.
10. The method of claim 9, wherein the communication is a message.
11. A method of providing communication with a thread, the method comprising:
generating a communication database that describes at least one communication characteristic of a communication interface that is defined in an interface description file;
requesting a database object to provide an identifier for each of the communications interfaces;
requesting the database object to access a selected one of the communications interfaces;
retrieving a reference to a communication object, wherein the communication object provides an interface for a COM-compliant application to access a communication that is owned by a thread that is executing on an embedded computer; and
storing data in at least one data field in the communication.
12. A method of providing communication with a thread, the method comprising:
retrieving a reference to a communication object, wherein the communication object provides an interface for a COM-compliant application to access a communication interface that is managed by a thread that is executing on an embedded computer; and
storing data in at least one data field in the communication.
13. A method of providing access to a communication, the method comprising:
providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and
accessing the communication interface via the COM-compliant application.
14. The method of claim 13, wherein the communication interface is owned by an embedded thread that is executing on an embedded computer, and wherein accessing the communication interface via the COM-compliant application comprises transmitting to the embedded thread at least one element of data from a thread that is executing remotely.
15. A system for providing access to a communication, the method comprising:
a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and
means for accessing the communication interface via the COM-compliant application.
16. The system of claim 15, wherein the communication interface is owned by an embedded thread that is executing on an embedded computer, and wherein the means for accessing the communication interface via the COM-compliant application comprises means for transmitting to the embedded thread at least one element of data from a thread that is executing on a host computer.
17. An executable communication object, the communication object comprising:
at least one application programming interface for accessing a communication interface from a COM-compliant application, wherein the application programming interface is selected from the group comprising:
a broadcasting interface for broadcasting the communication,
an interface for sending the communication,
a registration interface for registering the communication, and
a subscription interface for subscribing to the communication,
wherein each of the plurality of interfaces are automatically generated based, at least in part, information that is stored in an interface description file that describes a communication interface.
18. A system for communicating with a thread, the system comprising:
means for generating a communication database that describes at least one communication characteristic of a communication interface that is defined in an interface description file;
means for requesting a database object to provide an identifier for each of the communications interfaces;
means for requesting the database object to access a selected one of the communications interfaces;
means for retrieving a reference to a communication object, wherein the communication object provides an interface for a COM-compliant application to access a communication that is owned by a thread that is executing on an embedded computer; and
means for storing data in at least one data field in the communication.
19. A system for providing communication with a thread, the system comprising:
means for retrieving a reference to a communication object, wherein the communication object provides an interface for a COM-compliant application to access a communication interface that is owned by a thread that is executing on an embedded computer; and
means for storing data in at least one data field in the communication.
20. The system of claim 19, wherein the communication interface is a remote function call.
21. The system of claim 19, wherein the communication interface is a message.
22. A system for providing access to a communication, the system comprising:
means for providing a communication object that comprises at least one function for accessing a communication interface from a COM-compliant application; and
means for accessing the communication interface via the COM-compliant application.
23. A system for providing a communication interface that is accessible by a plurality of components, the system comprising:
a COM-compliant object;
at least one thread executing on an embedded computer; and
at least one communication module which is configured to provide an application programming interface for the COM-compliant object to communicate with the thread.
24. A system for providing a communication interface that is accessible by a plurality of components, the system comprising:
a scripting program; and
at least one communication module which is configured to provide an application programming interface for a COM-compliant object to communicate with the scripting program.
25. A system for providing a communication interface that is accessible by a plurality of components, the system comprising:
a COM-compliant object;
a scripting program;
a thread executing on a host computer;
a thread executing on an embedded computer; and
at least one communication module which is configured to provide an application programming interface for the COM-compliant object to communicate with the scripting program, the thread executing on the host computer, and the thread executing on the embedded computer.
US10/105,062 2001-03-23 2002-03-22 System and method for providing an interface for com-compliant applications to communicate with embedded systems Abandoned US20030061292A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US10/105,062 US20030061292A1 (en) 2001-03-23 2002-03-22 System and method for providing an interface for com-compliant applications to communicate with embedded systems
US11/061,283 US7530076B2 (en) 2001-03-23 2005-02-18 Dynamic interception of calls by a target device
US11/768,853 US20080016498A1 (en) 2001-03-23 2007-06-26 System and method for generating data sets for testing embedded systems
US12/435,998 US20090217292A1 (en) 2001-03-23 2009-05-05 System and method for testing devices
US12/985,242 US20110107348A1 (en) 2001-03-23 2011-01-05 System and method for storing persistent data objects

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US27821201P 2001-03-23 2001-03-23
US29955501P 2001-06-19 2001-06-19
US36343602P 2002-03-11 2002-03-11
US10/105,062 US20030061292A1 (en) 2001-03-23 2002-03-22 System and method for providing an interface for com-compliant applications to communicate with embedded systems

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/105,069 Continuation-In-Part US7237230B2 (en) 2001-03-23 2002-03-22 System and method for generating data sets for testing embedded systems

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US10/104,985 Continuation-In-Part US7062772B2 (en) 2001-03-23 2002-03-22 System and method for providing an interface for scripting programs to communicate with embedded systems
US11/061,283 Continuation-In-Part US7530076B2 (en) 2001-03-23 2005-02-18 Dynamic interception of calls by a target device
US11/768,853 Continuation US20080016498A1 (en) 2001-03-23 2007-06-26 System and method for generating data sets for testing embedded systems

Publications (1)

Publication Number Publication Date
US20030061292A1 true US20030061292A1 (en) 2003-03-27

Family

ID=27402975

Family Applications (11)

Application Number Title Priority Date Filing Date
US10/104,997 Expired - Fee Related US7020867B2 (en) 2001-03-23 2002-03-22 System and method for automatically generating code templates for communication via a predefined communication interface
US10/105,061 Expired - Fee Related US7111302B2 (en) 2001-03-23 2002-03-22 System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US10/105,062 Abandoned US20030061292A1 (en) 2001-03-23 2002-03-22 System and method for providing an interface for com-compliant applications to communicate with embedded systems
US10/104,985 Expired - Fee Related US7062772B2 (en) 2001-03-23 2002-03-22 System and method for providing an interface for scripting programs to communicate with embedded systems
US10/105,069 Expired - Fee Related US7237230B2 (en) 2001-03-23 2002-03-22 System and method for generating data sets for testing embedded systems
US10/104,989 Expired - Fee Related US7359911B2 (en) 2001-03-23 2002-03-22 System and method for building a database defining a plurality of communication interfaces
US11/391,026 Abandoned US20060179427A1 (en) 2001-03-23 2006-03-28 System and method for automatically generating code templates for communication via a predefined communication interface
US11/438,266 Abandoned US20060212880A1 (en) 2001-03-23 2006-05-22 System and method for providing an interface for scripting programs to communicate with embedded systems
US11/500,616 Expired - Fee Related US7392526B2 (en) 2001-03-23 2006-08-07 System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US11/768,853 Abandoned US20080016498A1 (en) 2001-03-23 2007-06-26 System and method for generating data sets for testing embedded systems
US11/864,670 Abandoned US20080052309A1 (en) 2001-03-23 2007-09-28 System and method for building a database defining a plurality of communication interfaces

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US10/104,997 Expired - Fee Related US7020867B2 (en) 2001-03-23 2002-03-22 System and method for automatically generating code templates for communication via a predefined communication interface
US10/105,061 Expired - Fee Related US7111302B2 (en) 2001-03-23 2002-03-22 System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics

Family Applications After (8)

Application Number Title Priority Date Filing Date
US10/104,985 Expired - Fee Related US7062772B2 (en) 2001-03-23 2002-03-22 System and method for providing an interface for scripting programs to communicate with embedded systems
US10/105,069 Expired - Fee Related US7237230B2 (en) 2001-03-23 2002-03-22 System and method for generating data sets for testing embedded systems
US10/104,989 Expired - Fee Related US7359911B2 (en) 2001-03-23 2002-03-22 System and method for building a database defining a plurality of communication interfaces
US11/391,026 Abandoned US20060179427A1 (en) 2001-03-23 2006-03-28 System and method for automatically generating code templates for communication via a predefined communication interface
US11/438,266 Abandoned US20060212880A1 (en) 2001-03-23 2006-05-22 System and method for providing an interface for scripting programs to communicate with embedded systems
US11/500,616 Expired - Fee Related US7392526B2 (en) 2001-03-23 2006-08-07 System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US11/768,853 Abandoned US20080016498A1 (en) 2001-03-23 2007-06-26 System and method for generating data sets for testing embedded systems
US11/864,670 Abandoned US20080052309A1 (en) 2001-03-23 2007-09-28 System and method for building a database defining a plurality of communication interfaces

Country Status (7)

Country Link
US (11) US7020867B2 (en)
EP (1) EP1438661A2 (en)
JP (2) JP2004532456A (en)
AU (1) AU2007202077B2 (en)
CA (1) CA2440321A1 (en)
IL (2) IL158007A0 (en)
WO (1) WO2002077813A2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020198675A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for generating data sets for testing embedded systems
US20040015315A1 (en) * 2002-07-19 2004-01-22 Kreider Thomas R Hardware device testing with fast abstract scripting tool
US20040044708A1 (en) * 2002-08-27 2004-03-04 Linke Scott L. Executable file system for an embedded computer
US20040260431A1 (en) * 2003-01-31 2004-12-23 Siemens Corporation Method and device for upgrading a building control system
US20050257191A1 (en) * 2001-03-23 2005-11-17 Mark Underseth System and method for testing devices
US20090193443A1 (en) * 2008-01-28 2009-07-30 Meenakshi Sundaram Lakshmanan Method and system for enhancing ms exchange (mapi) end user experiences in a split proxy environment
US20140337865A1 (en) * 2013-05-13 2014-11-13 Cisco Technology, Inc. Object-oriented class hierarchy for workflow execution targets

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7685252B1 (en) * 1999-10-12 2010-03-23 International Business Machines Corporation Methods and systems for multi-modal browsing and implementation of a conversational markup language
US8160863B2 (en) 2000-03-28 2012-04-17 Ionipas Transfer Company, Llc System and method for connecting a logic circuit simulation to a network
US7266490B2 (en) * 2000-12-28 2007-09-04 Robert Marc Zeidman Apparatus and method for connecting hardware to a circuit simulation
US20070016396A9 (en) * 2000-12-28 2007-01-18 Zeidman Robert M Apparatus and method for connecting a hardware emulator to a computer peripheral
US7203930B1 (en) * 2001-12-31 2007-04-10 Bellsouth Intellectual Property Corp. Graphical interface system monitor providing error notification message with modifiable indication of severity
US7243342B2 (en) * 2002-06-11 2007-07-10 Intel Corporation Methods and apparatus for determining if a user-defined software function is a memory allocation function during compile-time
US7316014B2 (en) * 2002-07-12 2008-01-01 Bsquare Corporation Application modification system and method
US20040024843A1 (en) * 2002-07-31 2004-02-05 Smith Christopher T. Method for provisioning distributed web applications
US7216340B1 (en) * 2002-08-19 2007-05-08 Sprint Communications Company L.P. Analysis data validation tool for use in enterprise architecture modeling with result based model updating
US7424702B1 (en) 2002-08-19 2008-09-09 Sprint Communications Company L.P. Data integration techniques for use in enterprise architecture modeling
KR101119216B1 (en) * 2003-07-02 2013-03-18 유나이티드 스테이츠 오브 어메리카, 에즈 리프레젠티드 바이 더 디파트먼트 오브 애그리컬쳐 Acapsular P. Multocida hyaE deletion mutants
US8381207B2 (en) * 2003-12-02 2013-02-19 International Business Machines Corporation Script generation engine and mapping semantic models for target platform
JP2006031482A (en) * 2004-07-16 2006-02-02 Toshiba Corp Profile management method and management system
US20060050856A1 (en) * 2004-09-03 2006-03-09 Pence Jeffrey W Computer telephony server for scripted call termination
US7490316B2 (en) * 2004-12-02 2009-02-10 International Business Machines Corporation Method and apparatus to implement adaptive scripting tool
US20060143222A1 (en) * 2004-12-23 2006-06-29 Maxime Daniel Method, program and system for automatic reengineering of a client code
US7954088B2 (en) * 2005-03-23 2011-05-31 Microsoft Corporation Method and apparatus for executing unit tests in application host environment
US8380682B2 (en) 2005-08-10 2013-02-19 International Business Machines Corporation Indexing and searching of electronic message transmission thread sets
US7565347B2 (en) * 2005-08-10 2009-07-21 International Business Machines Corporation Indexing and searching of electronic message transmission thread sets
US8402443B2 (en) * 2005-12-12 2013-03-19 dyna Trace software GmbH Method and system for automated analysis of the performance of remote method invocations in multi-tier applications using bytecode instrumentation
US7653895B1 (en) * 2006-01-20 2010-01-26 Xilinx, Inc. Memory arrangement for message processing by a plurality of threads
US8032874B1 (en) 2006-01-20 2011-10-04 Xilinx, Inc. Generation of executable threads having source code specifications that describe network packets
US7725922B2 (en) * 2006-03-21 2010-05-25 Novell, Inc. System and method for using sandboxes in a managed shell
US7743414B2 (en) * 2006-05-26 2010-06-22 Novell, Inc. System and method for executing a permissions recorder analyzer
US20080016023A1 (en) * 2006-07-17 2008-01-17 The Mathworks, Inc. Storing and loading data in an array-based computing environment
US7805707B2 (en) * 2006-07-21 2010-09-28 Novell, Inc. System and method for preparing runtime checks
US7739735B2 (en) * 2006-07-26 2010-06-15 Novell, Inc. System and method for dynamic optimizations using security assertions
US7856654B2 (en) * 2006-08-11 2010-12-21 Novell, Inc. System and method for network permissions evaluation
US7823186B2 (en) * 2006-08-24 2010-10-26 Novell, Inc. System and method for applying security policies on multiple assembly caches
US8762976B2 (en) * 2007-03-09 2014-06-24 Microsoft Corporation Static extensibility models with dynamic languages and scripts
KR101019210B1 (en) * 2007-04-25 2011-03-04 이화여자대학교 산학협력단 Test Device of Embedded Software using the emulator and Method thereof
US20080313620A1 (en) * 2007-06-15 2008-12-18 Spirent Communications, Inc. System and method for saving and restoring a self-describing data structure in various formats
US8752006B1 (en) * 2007-07-02 2014-06-10 Cisco Technology, Inc. System and method and apparatus for automatically generating computer code for remote procedure calls
US8255396B2 (en) * 2008-02-25 2012-08-28 Atigeo Llc Electronic profile development, storage, use, and systems therefor
RO122887B1 (en) * 2008-03-20 2010-03-30 G3 Nova Communications S.R.L. Method for connecting csta clients to a telephone exchange and telecommunication system
JP2009259089A (en) * 2008-04-18 2009-11-05 Nec Corp Device and method for tracking program execution path, and program
US8191036B2 (en) * 2008-05-19 2012-05-29 Apple Inc. Mechanism to support orphaned and partially configured objects
US20100262551A1 (en) * 2009-04-14 2010-10-14 Ppg Industries Ohio, Inc. Method and apparatus for digital coating project purchase
US8572554B2 (en) * 2009-07-17 2013-10-29 Ebay Inc. Method and system for integrating Java and JavaScript technologies
US8365057B2 (en) * 2009-07-30 2013-01-29 Mellanox Technologies Ltd Processing of data integrity field
WO2011031328A2 (en) * 2009-09-14 2011-03-17 Ldra Technology, Inc. Systems and methods for management of projects for development of embedded systems
US8225182B2 (en) 2009-10-04 2012-07-17 Mellanox Technologies Ltd. Processing of block and transaction signatures
US9065744B2 (en) * 2011-06-20 2015-06-23 Netscout Systems, Inc. Performance optimized and configurable state based heuristic for the classification of real-time transport protocol traffic
US8793669B2 (en) * 2012-07-17 2014-07-29 Concurix Corporation Pattern extraction from executable code in message passing environments
US9817638B2 (en) * 2013-12-27 2017-11-14 Symantec Corporation Systems and methods for injecting code into an application
CN104866383B (en) * 2015-05-29 2018-11-23 北京金山安全软件有限公司 Interface calling method and device and terminal
US10452409B2 (en) * 2015-10-23 2019-10-22 Oracle International Corporation Universal adapter for native calling
FR3043812B1 (en) * 2015-11-16 2019-07-26 Bull Sas METHOD FOR GENERATING A FORM OF MESSAGES
CN110309071B (en) * 2019-06-27 2023-01-24 杭州数梦工场科技有限公司 Test code generation method and module, and test method and system
US11010138B2 (en) * 2019-09-20 2021-05-18 Dell Products L.P. System and method for programmatically converting interface specification to generic plug-in code
US11531525B2 (en) * 2021-04-23 2022-12-20 Jpmorgan Chase Bank, N.A. System and method for packaging standalone application modules into re-usable application and infrastructure resources

Citations (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5510749A (en) * 1992-01-28 1996-04-23 Mitsubishi Denki Kabushiki Kaisha Circuitry and method for clamping a boost signal
US5600790A (en) * 1995-02-10 1997-02-04 Research In Motion Limited Method and system for loading and confirming correct operation of an application program in a target system
US5649131A (en) * 1992-12-30 1997-07-15 Lucent Technologies Inc. Communications protocol
US5749047A (en) * 1991-09-20 1998-05-05 Audio Precision Method and apparatus for recognizing a test signal and determining signal transfer characteristics therefrom
US5778228A (en) * 1994-08-16 1998-07-07 International Business Machines Corporation Method and system for transferring remote procedure calls and responses over a network
US5794047A (en) * 1994-09-29 1998-08-11 International Business Machines Corporation Method of walking-up a call stack for a client/server program that uses remote procedure call
US5799266A (en) * 1996-09-19 1998-08-25 Sun Microsystems, Inc. Automatic generation of test drivers
US5867153A (en) * 1996-10-30 1999-02-02 Transaction Technology, Inc. Method and system for automatically harmonizing access to a software application program via different access devices
US5872909A (en) * 1995-01-24 1999-02-16 Wind River Systems, Inc. Logic analyzer for software
US5978902A (en) * 1997-04-08 1999-11-02 Advanced Micro Devices, Inc. Debug interface including operating system access of a serial/parallel debug port
US5991778A (en) * 1997-09-30 1999-11-23 Stratfor Systems, Inc. Method and apparatus for real-time secure file deletion
US6002868A (en) * 1996-12-31 1999-12-14 Compaq Computer Corporation Test definition tool
US6014638A (en) * 1996-05-29 2000-01-11 America Online, Inc. System for customizing computer displays in accordance with user preferences
US6029181A (en) * 1996-09-26 2000-02-22 Honeywell, Inc. System and method for translating visual display object files from non-component object model (COM) objects to COM objects
US6038604A (en) * 1997-08-26 2000-03-14 International Business Machines Corporation Method and apparatus for efficient communications using active messages
US6066181A (en) * 1997-12-08 2000-05-23 Analysis & Technology, Inc. Java native interface code generator
US6070189A (en) * 1997-08-26 2000-05-30 International Business Machines Corporation Signaling communication events in a computer network
US6249821B1 (en) * 1995-07-14 2001-06-19 Oki Data Americas, Inc. Network object frameworks
US6275871B1 (en) * 1996-07-03 2001-08-14 Siemens Aktiengesellschaft Asynchronous transport optimizing observer-pattern-like system supporting several modes for an interface definition language-less communication subsystem
US6279123B1 (en) * 1997-09-15 2001-08-21 Lucent Technologies, Inc. System for viewing and monitoring embedded processor operation
US6279124B1 (en) * 1996-06-17 2001-08-21 Qwest Communications International Inc. Method and system for testing hardware and/or software applications
US20010025372A1 (en) * 1999-08-30 2001-09-27 Vermeire Dean R. Method of accessing data and logic on existing systems through dynamic construction of software components
US6314437B1 (en) * 1997-09-30 2001-11-06 Infraworks Corporation Method and apparatus for real-time secure file deletion
US6321347B1 (en) * 1998-07-06 2001-11-20 Mci Communications Corporation Network testing system and method
US20010049594A1 (en) * 2000-05-05 2001-12-06 Klevans Richard L. Method and system for hardware simulation
US20020032803A1 (en) * 1996-07-15 2002-03-14 Paul Marcos Method and apparatus for dynamically brokering object messages among object models
US6363417B1 (en) * 2000-03-31 2002-03-26 Emware, Inc. Device interfaces for networking a computer and an embedded device
US20020059560A1 (en) * 2000-04-20 2002-05-16 Mark Phillips Debugging device and method
US6397255B1 (en) * 1998-12-23 2002-05-28 At&T Corp. Method and apparatus for providing intelligent network services
US20020065945A1 (en) * 2000-11-29 2002-05-30 Brad Calder System and method for communicating and controlling the behavior of an application executing on a computer
US20020065869A1 (en) * 2000-11-29 2002-05-30 Brad Calder Method and process for virtualizing user interfaces
US6418439B1 (en) * 1997-11-12 2002-07-09 Ncr Corporation Computer system and computer implemented method for translation of information into multiple media variations
US20020092003A1 (en) * 2000-11-29 2002-07-11 Brad Calder Method and process for the rewriting of binaries to intercept system calls in a secure execution environment
US6421730B1 (en) * 1998-06-15 2002-07-16 Intel Corporation Programmable system for processing a partitioned network infrastructure
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US20020133807A1 (en) * 2000-11-10 2002-09-19 International Business Machines Corporation Automation and isolation of software component testing
US6473794B1 (en) * 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US6487713B1 (en) * 1999-09-24 2002-11-26 Phoenix Technologies Ltd. Software development system that presents a logical view of project components, facilitates their selection, and signals missing links prior to compilation
US20020188595A1 (en) * 2001-03-23 2002-12-12 Mark Underseth System and method for automatically generating code templates for communication via a predefined communication interface
US20020199035A1 (en) * 1996-06-24 2002-12-26 Erik B. Christensen Method and system for remote automation of object oriented applications
US6505342B1 (en) * 2000-05-31 2003-01-07 Siemens Corporate Research, Inc. System and method for functional testing of distributed, component-based software
US6507877B1 (en) * 1999-09-03 2003-01-14 Whamtech, Inc. Asynchronous concurrent dual-stream FIFO
US6546477B1 (en) * 1999-09-20 2003-04-08 Texas Instruments Incorporated Memory management in embedded systems with dynamic object instantiation
US6546553B1 (en) * 1998-10-02 2003-04-08 Microsoft Corporation Service installation on a base function and provision of a pass function with a service-free base function semantic
US6625648B1 (en) * 2000-01-07 2003-09-23 Netiq Corporation Methods, systems and computer program products for network performance testing through active endpoint pair based testing and passive application monitoring
US6681386B1 (en) * 2000-05-22 2004-01-20 International Business Machines Corporation Method, system, and program for parameter expansion, generation, and execution of scripts in a networked environment
US6721942B1 (en) * 2000-03-31 2004-04-13 Unisys Corporation Component object model interface to C++ type conversion
US6779134B1 (en) * 2000-06-27 2004-08-17 Ati International Srl Software test system and method
US20040205719A1 (en) * 2000-12-21 2004-10-14 Hooper Donald F. Hop method for stepping parallel hardware threads
US6807667B1 (en) * 1998-09-21 2004-10-19 Microsoft Corporation Method and system of an application program interface for abstracting network traffic control components to application programs
US6823460B1 (en) * 1999-11-14 2004-11-23 Networks Associates Technology, Inc. Method and system for intercepting an application program interface
US6832381B1 (en) * 1998-03-23 2004-12-14 Microsoft Corporation Application program interfaces and structures in a resource limited operating system
US6842903B1 (en) * 1999-05-19 2005-01-11 Sun Microsystems, Inc. System and method for providing dynamic references between services in a computer system
US6851117B2 (en) * 2001-05-25 2005-02-01 Sun Microsystems, Inc. Supplanting motif dialog boxes via modifying intercepted function calls from an application
US6865599B2 (en) * 2001-09-04 2005-03-08 Chenglin Zhang Browser-to-browser, dom-based, peer-to-peer communication with delta synchronization
US20050080905A1 (en) * 1999-11-09 2005-04-14 Larry Dolinar Providing telephony services in a communications network
US6892328B2 (en) * 2000-09-29 2005-05-10 Tanisys Technology, Inc. Method and system for distributed testing of electronic devices
US20050183072A1 (en) * 1999-07-29 2005-08-18 Intertrust Technologies Corporation Software self-defense systems and methods
US6938246B2 (en) * 2000-05-08 2005-08-30 Microtune (San Diego), Inc. Diagnostic tool for a portable thread environment
US20050257191A1 (en) * 2001-03-23 2005-11-17 Mark Underseth System and method for testing devices
US7013345B1 (en) * 2000-06-12 2006-03-14 Metric Systems Corporation Method and apparatus for wireless networking
US7058930B2 (en) * 1999-12-16 2006-06-06 Matsushita Electric Works, Ltd. Distributed program relocation for a computer system
US7363633B1 (en) * 2000-04-24 2008-04-22 Microsoft Corporation Registering and storing dependencies among applications and objects in a computer system and communicating the dependencies to a recovery or backup service

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3279124A (en) * 1964-07-20 1966-10-18 Brown Co D S Corner portions for elastomer gaskets
US6006277A (en) * 1987-11-06 1999-12-21 Bea Systems, Inc. Virtual software machine for enabling CICS application software to run on UNIX based computer systems
US5701427A (en) * 1989-09-19 1997-12-23 Digital Equipment Corp. Information transfer arrangement for distributed computer system
US5497463A (en) * 1992-09-25 1996-03-05 Bull Hn Information Systems Inc. Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system
US5530848A (en) * 1992-10-15 1996-06-25 The Dow Chemical Company System and method for implementing an interface between an external process and transaction processing system
JPH0827769B2 (en) * 1992-10-30 1996-03-21 インターナショナル・ビジネス・マシーンズ・コーポレイション Communication interface generation system and method
GB9316948D0 (en) * 1993-08-14 1993-09-29 Ibm Programming aid for distributed computing systems
WO1996017306A2 (en) * 1994-11-21 1996-06-06 Oracle Corporation Media server
US7770013B2 (en) * 1995-07-27 2010-08-03 Digimarc Corporation Digital authentication with digital and analog documents
IL116804A (en) 1996-01-17 1998-12-06 R N S Remote Networking Soluti Application user interface redirector
US5926636A (en) * 1996-02-21 1999-07-20 Adaptec, Inc. Remote procedural call component management method for a heterogeneous computer network
TW347498B (en) * 1996-09-30 1998-12-11 Casio Computer Co Ltd Information supply system
US6047280A (en) * 1996-10-25 2000-04-04 Navigation Technologies Corporation Interface layer for navigation system
US6658486B2 (en) * 1998-02-25 2003-12-02 Hewlett-Packard Development Company, L.P. System and method for efficiently blocking event signals associated with an operating system
US6205576B1 (en) * 1998-06-05 2001-03-20 Nortel Networks Limited Method and apparatus for identifying indirect messaging relationships between software entities
US6971048B1 (en) 1998-06-15 2005-11-29 Sun Microsystems, Inc. Testing device driver hardening
US20010051974A1 (en) * 1998-06-23 2001-12-13 Ron Saad Method and apparatus for automatic generation of data interfaces
DE19828253B4 (en) * 1998-06-25 2006-04-06 Daimlerchrysler Ag Exterior rear view mirror
US6629123B1 (en) * 1998-10-02 2003-09-30 Microsoft Corporation Interception of unit creation requests by an automatic distributed partitioning system
US6477683B1 (en) * 1999-02-05 2002-11-05 Tensilica, Inc. Automated processor generation system for designing a configurable processor and method for the same
US6493719B1 (en) * 1999-07-26 2002-12-10 Microsoft Corporation Method and system for scripting for system management information
US7406681B1 (en) * 2000-10-12 2008-07-29 Sun Microsystems, Inc. Automatic conversion of source code from 32-bit to 64-bit
US7171670B2 (en) * 2001-02-14 2007-01-30 Ricoh Co., Ltd. Method and system of remote diagnostic, control and information collection using multiple formats and multiple protocols with verification of formats and protocols
US7325185B1 (en) * 2003-08-04 2008-01-29 Symantec Corporation Host-based detection and prevention of malicious code propagation

Patent Citations (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5749047A (en) * 1991-09-20 1998-05-05 Audio Precision Method and apparatus for recognizing a test signal and determining signal transfer characteristics therefrom
US5510749A (en) * 1992-01-28 1996-04-23 Mitsubishi Denki Kabushiki Kaisha Circuitry and method for clamping a boost signal
US5649131A (en) * 1992-12-30 1997-07-15 Lucent Technologies Inc. Communications protocol
US5778228A (en) * 1994-08-16 1998-07-07 International Business Machines Corporation Method and system for transferring remote procedure calls and responses over a network
US5794047A (en) * 1994-09-29 1998-08-11 International Business Machines Corporation Method of walking-up a call stack for a client/server program that uses remote procedure call
US5872909A (en) * 1995-01-24 1999-02-16 Wind River Systems, Inc. Logic analyzer for software
US5600790A (en) * 1995-02-10 1997-02-04 Research In Motion Limited Method and system for loading and confirming correct operation of an application program in a target system
US5715387A (en) * 1995-02-10 1998-02-03 Research In Motion Limited Method and system for loading and confirming correct operation of an application program in a target system
US6249821B1 (en) * 1995-07-14 2001-06-19 Oki Data Americas, Inc. Network object frameworks
US6014638A (en) * 1996-05-29 2000-01-11 America Online, Inc. System for customizing computer displays in accordance with user preferences
US6279124B1 (en) * 1996-06-17 2001-08-21 Qwest Communications International Inc. Method and system for testing hardware and/or software applications
US20020199035A1 (en) * 1996-06-24 2002-12-26 Erik B. Christensen Method and system for remote automation of object oriented applications
US6275871B1 (en) * 1996-07-03 2001-08-14 Siemens Aktiengesellschaft Asynchronous transport optimizing observer-pattern-like system supporting several modes for an interface definition language-less communication subsystem
US20020032803A1 (en) * 1996-07-15 2002-03-14 Paul Marcos Method and apparatus for dynamically brokering object messages among object models
US5799266A (en) * 1996-09-19 1998-08-25 Sun Microsystems, Inc. Automatic generation of test drivers
US6029181A (en) * 1996-09-26 2000-02-22 Honeywell, Inc. System and method for translating visual display object files from non-component object model (COM) objects to COM objects
US5867153A (en) * 1996-10-30 1999-02-02 Transaction Technology, Inc. Method and system for automatically harmonizing access to a software application program via different access devices
US6002868A (en) * 1996-12-31 1999-12-14 Compaq Computer Corporation Test definition tool
US5978902A (en) * 1997-04-08 1999-11-02 Advanced Micro Devices, Inc. Debug interface including operating system access of a serial/parallel debug port
US6038604A (en) * 1997-08-26 2000-03-14 International Business Machines Corporation Method and apparatus for efficient communications using active messages
US6070189A (en) * 1997-08-26 2000-05-30 International Business Machines Corporation Signaling communication events in a computer network
US6279123B1 (en) * 1997-09-15 2001-08-21 Lucent Technologies, Inc. System for viewing and monitoring embedded processor operation
US5991778A (en) * 1997-09-30 1999-11-23 Stratfor Systems, Inc. Method and apparatus for real-time secure file deletion
US6314437B1 (en) * 1997-09-30 2001-11-06 Infraworks Corporation Method and apparatus for real-time secure file deletion
US6418439B1 (en) * 1997-11-12 2002-07-09 Ncr Corporation Computer system and computer implemented method for translation of information into multiple media variations
US6066181A (en) * 1997-12-08 2000-05-23 Analysis & Technology, Inc. Java native interface code generator
US6832381B1 (en) * 1998-03-23 2004-12-14 Microsoft Corporation Application program interfaces and structures in a resource limited operating system
US20050102687A1 (en) * 1998-03-23 2005-05-12 Microsoft Corporation Application program interfaces and structures in a resource limited operating system
US6421730B1 (en) * 1998-06-15 2002-07-16 Intel Corporation Programmable system for processing a partitioned network infrastructure
US6321347B1 (en) * 1998-07-06 2001-11-20 Mci Communications Corporation Network testing system and method
US6807667B1 (en) * 1998-09-21 2004-10-19 Microsoft Corporation Method and system of an application program interface for abstracting network traffic control components to application programs
US6546553B1 (en) * 1998-10-02 2003-04-08 Microsoft Corporation Service installation on a base function and provision of a pass function with a service-free base function semantic
US6397255B1 (en) * 1998-12-23 2002-05-28 At&T Corp. Method and apparatus for providing intelligent network services
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US6842903B1 (en) * 1999-05-19 2005-01-11 Sun Microsystems, Inc. System and method for providing dynamic references between services in a computer system
US6473794B1 (en) * 1999-05-27 2002-10-29 Accenture Llp System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US20050183072A1 (en) * 1999-07-29 2005-08-18 Intertrust Technologies Corporation Software self-defense systems and methods
US20010025372A1 (en) * 1999-08-30 2001-09-27 Vermeire Dean R. Method of accessing data and logic on existing systems through dynamic construction of software components
US6507877B1 (en) * 1999-09-03 2003-01-14 Whamtech, Inc. Asynchronous concurrent dual-stream FIFO
US6546477B1 (en) * 1999-09-20 2003-04-08 Texas Instruments Incorporated Memory management in embedded systems with dynamic object instantiation
US6487713B1 (en) * 1999-09-24 2002-11-26 Phoenix Technologies Ltd. Software development system that presents a logical view of project components, facilitates their selection, and signals missing links prior to compilation
US20050080905A1 (en) * 1999-11-09 2005-04-14 Larry Dolinar Providing telephony services in a communications network
US6823460B1 (en) * 1999-11-14 2004-11-23 Networks Associates Technology, Inc. Method and system for intercepting an application program interface
US7058930B2 (en) * 1999-12-16 2006-06-06 Matsushita Electric Works, Ltd. Distributed program relocation for a computer system
US6625648B1 (en) * 2000-01-07 2003-09-23 Netiq Corporation Methods, systems and computer program products for network performance testing through active endpoint pair based testing and passive application monitoring
US6363417B1 (en) * 2000-03-31 2002-03-26 Emware, Inc. Device interfaces for networking a computer and an embedded device
US6721942B1 (en) * 2000-03-31 2004-04-13 Unisys Corporation Component object model interface to C++ type conversion
US20020059560A1 (en) * 2000-04-20 2002-05-16 Mark Phillips Debugging device and method
US7363633B1 (en) * 2000-04-24 2008-04-22 Microsoft Corporation Registering and storing dependencies among applications and objects in a computer system and communicating the dependencies to a recovery or backup service
US20010049594A1 (en) * 2000-05-05 2001-12-06 Klevans Richard L. Method and system for hardware simulation
US6938246B2 (en) * 2000-05-08 2005-08-30 Microtune (San Diego), Inc. Diagnostic tool for a portable thread environment
US6681386B1 (en) * 2000-05-22 2004-01-20 International Business Machines Corporation Method, system, and program for parameter expansion, generation, and execution of scripts in a networked environment
US6505342B1 (en) * 2000-05-31 2003-01-07 Siemens Corporate Research, Inc. System and method for functional testing of distributed, component-based software
US7013345B1 (en) * 2000-06-12 2006-03-14 Metric Systems Corporation Method and apparatus for wireless networking
US6779134B1 (en) * 2000-06-27 2004-08-17 Ati International Srl Software test system and method
US6892328B2 (en) * 2000-09-29 2005-05-10 Tanisys Technology, Inc. Method and system for distributed testing of electronic devices
US20020133807A1 (en) * 2000-11-10 2002-09-19 International Business Machines Corporation Automation and isolation of software component testing
US20020065945A1 (en) * 2000-11-29 2002-05-30 Brad Calder System and method for communicating and controlling the behavior of an application executing on a computer
US20020065869A1 (en) * 2000-11-29 2002-05-30 Brad Calder Method and process for virtualizing user interfaces
US20020092003A1 (en) * 2000-11-29 2002-07-11 Brad Calder Method and process for the rewriting of binaries to intercept system calls in a secure execution environment
US20040205719A1 (en) * 2000-12-21 2004-10-14 Hooper Donald F. Hop method for stepping parallel hardware threads
US20020198893A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US20020198887A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for building a database defining a plurality of communication interfaces
US20020188595A1 (en) * 2001-03-23 2002-12-12 Mark Underseth System and method for automatically generating code templates for communication via a predefined communication interface
US20020198922A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for providing an interface for scripting programs to communicate with embedded systems
US20050257191A1 (en) * 2001-03-23 2005-11-17 Mark Underseth System and method for testing devices
US20020198675A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for generating data sets for testing embedded systems
US20060179427A1 (en) * 2001-03-23 2006-08-10 Mark Underseth System and method for automatically generating code templates for communication via a predefined communication interface
US20060212880A1 (en) * 2001-03-23 2006-09-21 Mark Underseth System and method for providing an interface for scripting programs to communicate with embedded systems
US20060282507A1 (en) * 2001-03-23 2006-12-14 Mark Underseth System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US6851117B2 (en) * 2001-05-25 2005-02-01 Sun Microsystems, Inc. Supplanting motif dialog boxes via modifying intercepted function calls from an application
US6865599B2 (en) * 2001-09-04 2005-03-08 Chenglin Zhang Browser-to-browser, dom-based, peer-to-peer communication with delta synchronization

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080016498A1 (en) * 2001-03-23 2008-01-17 S2 Technologies, Inc. System and method for generating data sets for testing embedded systems
US7530076B2 (en) 2001-03-23 2009-05-05 S2 Technologies, Inc. Dynamic interception of calls by a target device
US7237230B2 (en) 2001-03-23 2007-06-26 S2 Technologies, Inc. System and method for generating data sets for testing embedded systems
US20090217292A1 (en) * 2001-03-23 2009-08-27 S2 Technologies, Inc. System and method for testing devices
US20020198887A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for building a database defining a plurality of communication interfaces
US20020198675A1 (en) * 2001-03-23 2002-12-26 Mark Underseth System and method for generating data sets for testing embedded systems
US20050257191A1 (en) * 2001-03-23 2005-11-17 Mark Underseth System and method for testing devices
US20060179427A1 (en) * 2001-03-23 2006-08-10 Mark Underseth System and method for automatically generating code templates for communication via a predefined communication interface
US20060212880A1 (en) * 2001-03-23 2006-09-21 Mark Underseth System and method for providing an interface for scripting programs to communicate with embedded systems
US20060282507A1 (en) * 2001-03-23 2006-12-14 Mark Underseth System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US7359911B2 (en) 2001-03-23 2008-04-15 S2 Technologies, Inc. System and method for building a database defining a plurality of communication interfaces
US7392526B2 (en) 2001-03-23 2008-06-24 S2 Technologies, Inc. System and method for formatting data for transmission between an embedded computer and a host computer having different machine characteristics
US6839649B2 (en) * 2002-07-19 2005-01-04 Honeywell International Inc. Hardware device testing with fast abstract scripting tool
US20040015315A1 (en) * 2002-07-19 2004-01-22 Kreider Thomas R Hardware device testing with fast abstract scripting tool
US20040044708A1 (en) * 2002-08-27 2004-03-04 Linke Scott L. Executable file system for an embedded computer
US7178139B2 (en) * 2002-08-27 2007-02-13 Delphi Technologies, Inc. Executable file system for an embedded computer
US8850346B2 (en) * 2003-01-31 2014-09-30 Siemens Industry, Inc. Method and device for upgrading a building control system
US7464339B2 (en) * 2003-01-31 2008-12-09 Siemens Building Technologies, Inc. Method and device for upgrading a building control system
US20040260431A1 (en) * 2003-01-31 2004-12-23 Siemens Corporation Method and device for upgrading a building control system
US20090228812A1 (en) * 2003-01-31 2009-09-10 Keenan Jr Duane Method and device for upgrading a building control system
US20090193443A1 (en) * 2008-01-28 2009-07-30 Meenakshi Sundaram Lakshmanan Method and system for enhancing ms exchange (mapi) end user experiences in a split proxy environment
US8505038B2 (en) * 2008-01-28 2013-08-06 Blue Coat Systems, Inc. Method and system for enhancing MS exchange (MAPI) end user experiences in a split proxy environment
US8949866B2 (en) * 2013-05-13 2015-02-03 Cisco Technology, Inc. Object-oriented class hierarchy for workflow execution targets
US20140337865A1 (en) * 2013-05-13 2014-11-13 Cisco Technology, Inc. Object-oriented class hierarchy for workflow execution targets

Also Published As

Publication number Publication date
CA2440321A1 (en) 2002-10-03
US7062772B2 (en) 2006-06-13
US20080016498A1 (en) 2008-01-17
US20060212880A1 (en) 2006-09-21
IL158007A (en) 2009-09-22
US20080052309A1 (en) 2008-02-28
EP1438661A2 (en) 2004-07-21
JP2008251032A (en) 2008-10-16
WO2002077813A2 (en) 2002-10-03
WO2002077813A8 (en) 2004-03-25
US7237230B2 (en) 2007-06-26
AU2007202077B2 (en) 2008-08-07
US20020188595A1 (en) 2002-12-12
AU2007202077A1 (en) 2007-05-31
US20020198893A1 (en) 2002-12-26
US7020867B2 (en) 2006-03-28
JP2004532456A (en) 2004-10-21
IL158007A0 (en) 2004-03-28
US20060179427A1 (en) 2006-08-10
US20060282507A1 (en) 2006-12-14
US7392526B2 (en) 2008-06-24
US20020198922A1 (en) 2002-12-26
US7359911B2 (en) 2008-04-15
US7111302B2 (en) 2006-09-19
US20020198887A1 (en) 2002-12-26
US20020198675A1 (en) 2002-12-26

Similar Documents

Publication Publication Date Title
US7237230B2 (en) System and method for generating data sets for testing embedded systems
US7530076B2 (en) Dynamic interception of calls by a target device
JP3822541B2 (en) Computer system for passing a pointer to an object interface
US5212792A (en) Method and apparatus for controlling execution of tools in a computer-aided software engineering system
US7225426B2 (en) Dynamic objects with property slot definition and runtime mechanisms
US7739693B2 (en) Generic application program interface for native drivers
US5539909A (en) Negotiation method for calling procedures located within other objects without knowledge of their calling syntax
US6574673B1 (en) Data type mapping for external callouts
WO1991009365A2 (en) Computer-assisted software engineering for cooperative processing
AU2002247399B2 (en) Development and testing system and method
US7552440B1 (en) Process communication multiplexer
AU2002247399A1 (en) Development and testing system and method

Legal Events

Date Code Title Description
AS Assignment

Owner name: S2 TECHNOLOGIES, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:UNDERSETH, MARK;FERTITTA, KIRK;VALOIS, HUGUES;REEL/FRAME:013068/0690

Effective date: 20020610

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION