The present invention relates generally to a data processing system for modeling and implementation of scalable distributed systems that perform various tasks, and more particularly to a scalable architecture-based data processing system for simplified design, prototyping, and rapid implementation of task performance systems, including, but not limited to, industrial process control systems, other embedded systems, multi-component electrical, electronic, or electromechanical devices, and distributed computer systems.
Traditionally, the process of design, prototyping and implementation of complex industrial applications (such as manufacturing process control, multi-component devices and other systems or devices), has been an extremely difficult, costly and time consuming task. Typically, this process involved a long iterative, and often empirical, process, of formulating the requirements of the desired system, conceptually planning the system, developing a prototype, writing programs or other code necessary for implementation, testing the implemented prototype and then repeating many of the steps, in most cases including the arduous and frustrating coding of new programs, even when minor changes to the prototype are necessary. In cases of more serious issues, the entire system is often re-designed further consuming a great deal of time and resources. This trial and error approach of system and device design has been a challenge for engineers and designers for years.
However, as data processing systems came into increased use in the last several decades, attempts have been made to automate and simplify at least some of the steps involved in system design, prototyping, and implementation, both for design of new systems and for modification, re-engineering and improvement of existing industrial systems. Thus, as data processing (i.e. computer) systems have gained increased utilization in the field of system and device design, a great deal of effort was directed toward providing engineers and system designers with powerful software tools that simplify the difficult goal of designing and modeling a system (e.g., industrial, computer, process control, etc.) or an apparatus (e.g., automobile exhaust system, engine, motor, etc.) in a software environment. The ultimate goal of these tools was to enable the user (e.g., the engineer) to design a software model of the desired system, simulate the model to ensure proper system operation, and hopefully assist the user in implementing the modeled system in real-world devices.
Nevertheless, even with the aid of currently available powerful software tools, prototyping of a complex system or apparatus which generally requires a distributed architecture for its various operational parameters (such as an industrial process control application), it is a difficult and time consuming process with at least the following steps that must be performed by the user as part of the design to implementation cycle:
1) Design the desired target system functionality;
2) Break down the target system manually into distributed target components requiring slight modification in design, model each component and their connections separately to correspond to a real-world target device or system, and assign a portion of the desired functionality to each component, and establish connections between appropriate components;
3) Write appropriate software code to cause each component to perform their assigned functionality as well as to ensure proper communication and data interchange between various components
3) Simulate the operation of the system, testing and monitoring one component at a time; and
4) Manage the system (i.e., issue commands such as start, stop, record progress or status), one component at a time.
5) If problems occur, repeat one or more of the previous steps until the target system performs acceptably.
Because the key actions for all of the above tasks must be performed manually by the user, even with the assistance of the most powerful currently available design tools, the design-to-implementation cycle in continuous product development industries (such as automotive and aerospace industries), remains undesirably long. In addition, changes to the system architecture or to system components during the prototyping process must be manually propagated through the entire system, thus resulting in a further significant delay and expense. Furthermore, the most frustrating and difficult tasks for the user of previously known system design software tools—the second and third steps shown above—are still an ever-present requirement. Thus, the user must still engage in the manual and time-intensive partitioning of the designed system into multiple components corresponding to various real-world hardware systems and writing a great deal of code each time a change to any aspect of the system must be made (e.g., moving an element of a model to a different partition to relieve the load on a target component), but now utilizing an attractive graphical user interface to do so. And with many design systems, after the design and prototype modeling process is complete, appropriate software code must be manually generated for each target system component.
The above issues are due at least in part to the fact that the great deal of the advancements in the system design and modeling tools have been directed to improvements of preliminary system design capabilities, for example to provide users with innovative and easy to use graphical design tools, to enable visual concept-to-design model development, and to otherwise shorten the concept-to-design cycles, to enable improved computerized design simulation. Others directed their research and development to offering improvements and innovations in hardware target components, resulting in relatively inexpensive and powerful embedded system target components that may be utilized to emulate real-world physical components or that may be used as production target components themselves. Accordingly, the area between the two has been largely neglected or ignored. Finally, the majority of existing design software tools are generally limited to utilization in the field of embedded system design and cannot be readily used in other forms of distributed task performance systems.
It would thus be desirable to provide a system and method for simplifying the processes of virtually any task performance system or device prototyping and implementation, and thereby reducing the design-to-implementation cycle time. It would also be desirable to provide an integrated system and method that may be used as a tool by itself or in conjunction with existing visual system design tools for rapid and inexpensive design, prototyping, re-design, scaling, modification, and/or testing of task performance systems. It would further be desirable to provide a system and method for automatically generating necessary code for implementing the designed task performance systems. It would additionally be desirable to provide a system and method for enabling the user to utilize an available existing graphical user interface for improving the ease and speed of the task performance system prototyping and implementation processes.
In the drawings, wherein like reference characters denote corresponding or similar elements throughout the various figures:
FIGS. 11 to 12 show a process flow diagram, and a related exemplary supporting diagram, of an inventive process for automatically generating executable modules for implementation in a desired target system from the partitioned system model, during the execution of the process of
The present invention is directed to a system and method for simplifying and accelerating the process of prototyping, real-world simulation, and implementation of virtually any task performance system or device, thereby dramatically reducing the design-to-implementation cycle time and expense. The inventive system includes a development system that provides a user, with visual tools to interactively and dynamically partition a previously designed visual system model of the task performance system or device, and then interactively or automatically assign the partitions to corresponding selectable target components, to produce a prototyped system ready for conversion to executable form suitable for implementation. The inventive system and method can also be readily used to automatically generate any instruction sets (e.g. programs, drivers, or modules) that are necessary for implementing the prototyped task performance system in actual target components of one or more emulation and/or production target systems. A novel automatic executable program code generation process that can be advantageously utilized is also provided in accordance with the present invention.
In summary, the inventive system delivers the above functionality via a development system (that may range in features and other aspects from a pocket computer to a network of powerful computers) that interactively executes one or more novel processes in response to user commands that may be issued through the system's graphical user interface. If implementation of the prototyped task performance system is desired, the novel system may be connected to a target system to implement therein, executable code modules representative of the prototyped system, that were generated during the performance of one or more novel processes.
Advantageously, the inventive processes performed by the system of the present invention, are applicable to any visual system model that may be created with any form of visual design and/or modeling tools. While the inventive system may be readily implemented in a stand-alone configuration independent of any other design or modeling tools or environments, as a matter of design choice, it may be utilized in conjunction with existing visual system design tools for rapid and inexpensive design, prototyping, re-design, scaling, modification, and/or testing of task performance systems. This approach is very attractive because the user is able utilize an available and familiar graphical user interface and controls of the initial design system and at the same time use all of the novel features and capabilities provided in accordance with the present invention.
The system of the present invention may include an optional data handling system located as a component of, or proximal to, the implementation target system for enabling real time transmission of date from the target system to a remote development or other user system. Furthermore, the development system of the present invention, may be provided with an interactive user interface, at its output (i.e. display) system with novel tools and functionality that enable the user to readily design an interactive reconfigurable visual instrument panel for monitoring and/or management one or more remote target systems or devices.
Due to the novel features of the present invention, the prototyped model (or even the visual design model) may be quickly and easily modified at any time, for example, to account for changes in design or engineering requirements, target system factors, or to take advantage of new technologies, and/or lower-cost target components, without requiring the user to extensively re-design the visual model, or to write any program code.
Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims.
The system and method of the present invention remedy the disadvantages of all previously known system design software tools. In essence, the inventive rapid design, prototyping, and implementation (hereinafter “RDPI”) system gives its user the ability to quickly and easily move from a designed visual model of a task control and/or performance system or apparatus, that may be created with any form of visual design and/or modeling tools, to a real-time interactive prototype model representative of the actual desired real-world system or apparatus (hereinafter “target system”). The user may then utilize the RDPI system to automatically generate and/or assemble any instruction modules and necessary support modules based on the prototype model, that may be directed to a physical real-world target system, corresponding to the prototype model, to implement the designed task performance system or apparatus for desired utilization.
Advantageously, due to the novel features of the present invention, the interactive prototype model (or even the visual design model) may be quickly and easily modified at any time, for example, to account for changes in design or engineering requirements, target system factors, or to take advantage of new technologies, and/or lower-cost target components, without requiring the user to extensively re-design the visual model, or to write any program code. This is a crucial advantage in any design/prototyping process, especially for complex systems, where ordinarily many expensive and time consuming re-design and prototyping iterations would need to take place as a matter of course. Thus, in contrast to previously known design tools, the inventive RDPI system enables real-time interactive modification of a prototype model, or of the visual design model (depending on the scope of the desired changes), and subsequent optional automatic instruction module generation for target system implementation, so that the newly modified target system may be readily utilized.
Other advantages of the RDPI system, are its scalable architecture and visual design tool/platform independence. Because the RDPI system can work with any visual model in any format (if necessary, with simple utilization of appropriate readily available conversion tools) it may be readily used in a virtually unlimited range of application in various industries, from automotive design and/or manufacturing to home automation systems, or home electronics.
Moreover, the RDPI system's scalable architecture enables the user to work with designed visual models for target systems of any scope from a simple electrical or electromechanical devices with two or more components, or an internal combustion engine, to complex automated manufacturing facilities or distributed computer or telecommunication networks with hundreds or thousands of components.
In summary, the RDPI system advantageous accomplishes its goals by:
Thus, the inventive RDPI system significantly automates and simplifies the prototyping process there by reducing design, prototyping and implementation expenses and shortening the design to implementation cycle. Furthermore, the inventive system provides a scalable and flexible architecture that with a minimum of effort enables scalability of the designed system in different implementation configurations, and also enables simplified modification of an existing designed system (for changing, re-engineering or upgrading the system).
In particular, the inventive RDPI system provides many significant advantages in industries with continuous or long-term product development cycles, such as in the automotive and airspace industries (for example, in vehicle development or development of manual, semi-autonomous, or autonomous systems).
While the inventive RDPI system is described below as advantageously configured, by way of example, for industrial process (or process control) design and for distributed embedded systems, it should be understood to one skilled in the art, that, as noted above, the RDPI system may be readily and advantageously utilized for prototyping and implementation of any system or device with two or more functioning components capable of receiving instructions, including, but not limited to process control systems, automated industrial systems (fabrication, packaging, sorting, etc), distributed electromechanical systems, embedded systems of various functionalities (control and otherwise), electrical devices, electromechanical devices, and distributed computational systems, for example, for massive computational processes such as military, research, or meteorological applications, without departing from the spirit of the invention as a matter of necessity or design choice.
Before describing the inventive RDPI system in greater detail, it would be helpful to provide an overview of the various types of target systems that may be designed and implemented in accordance with the present invention, and of the various target components that may be utilized therein. The simplest target system may include as little as two target components, but a more complex target system may include a far greater number of target components as a matter of design choice. While an actual real-world target system or device may have many physical components, such as a housing, mechanical elements such as gears, or other features, the inventive RDPI system is only concerned with functional components of the target system that are capable of performing one or more actions in response to internal instructions or received commands. The target components themselves can vary from simple to complex.
Referring now to
The RDPI system 10 includes a development system 12 for enabling the user to quickly and easily create an operational system model (representative of a previously designed visual system model partitioned into individual model elements and/or model element groups (i.e., “partitions”) intended for assignment to particular target components, as well as the necessary communication links therebetween), and to create a target system model in which the partitions are assigned to selected target components for future implementation. The RDPI system 10 may also include an optional target system 14, if implementation of the operational system model created by the user is desired. An exemplary previously designed visual system model is described below in connection with
The development system 12 may be any interactive device or system capable of enabling the user to work with a previously designed visual system model, to create a desired target system model, and to optionally generate the instruction modules necessary for its implementation, for example, if implementation in an optional target system 14 is available. Thus, at a minimum, the development system 12 is preferably capable of:
For example, the development system 12 may be any computer system with at least the above-listed capabilities, including, but not limited to: a small computer (e.g. a pocket computer or equivalent), a portable computer (e.g., a notebook or touchpanel computer, or equivalent), a workstation (or equivalent), or a terminal of a local or remote computer system. As a matter of design choice, the development system 12, may be capable of performing other tasks, in addition to those that are required by the RDPI system 10, or for example, it may be a dedicated or proprietary system optimized for meeting the RDPI system 10 demands. Optionally, the development system 12 may be implemented as two or more interconnected computer systems, to either distribute the task load imposed by the RDPI system 10 or to allow two or more users to collaborate on the design and prototyping process.
The development system 12 includes the following elements (that may be separate components connected to one or more other components, or that may be integrated with one or more of the other components as a single unit): a DSO device 20 for controlling the various components of the development system 12, executing performing one or more inventive processes, executing other programs, storing data, and equivalent tasks, an input system 22 for receiving instructions and information from the user, and an output system 24 for conveying information to the user.
The DSO device 20 is preferably a main computer assembly or unit that may include, but is not limited to:
The output system 24 preferably includes a display system for displaying visual information to the user, such as one or more monitors, an optional sound system, such as speakers or headphones, and an optional hard copy system, such as a printer, or equivalent.
The input system 22 preferably includes at least one data input device for enabling the user to interact with the development system 12. For example, the input system 24 includes one or more of the following input devices: a keyboard, a selection device (i.e. mouse, trackball, or touchpad), an optionally a voice recognition device. Optionally, the input system 22 may include a security system (for example, a biometric device such as a fingerprint scanner, face recognition device, or a retinal scanner) for receiving identity verification data from the user prior to allowing the user to utilize the RDPI system 10. For example, it may be a biometric device such as a fingerprint scanner, face recognition device, or a retinal scanner.
It should be understood that the choice of a specific type or configuration of the development system 12, and its types and features of its various components, is determined by requirements that depend on the purposes for which the RDPI system 10 will be used (e.g., the complexity of the system being designed, whether or not the user wishes to generate instruction modules for implementation, etc.)
The optional target system 14 may be any target system configured to correspond to a target system model created by the user utilizing the development system 12. Various types and configurations of target systems are described above, and several exemplary target systems are discussed below in connection with
It should be understood, that the key goals of the present invention—greatly accelerating and simplifying the task of system prototyping, design and preparation for implementation, do not rely on the availability of the target system 14. The target system 14 is only necessary if implementation of instruction modules generated from the operational and target system models at the development system 12 is necessary or desired. Thus, it should be understood that the entire RDPI system 10 may be implemented solely in the development system 12, as a mater of design choice or necessity, without departing from the spirit of the invention. nevertheless, to provide a better overview of the novel features of the present invention, it would be convenient to presume, by way of example, that the optional target system 14 is present for the purpose of the discussion of the inventive RDPI system 10.
The development system 12 communicates with the target system 14 via a communication link 16, which may be any communication link that enables bi-directional transmission of information. Examples of communication links 16 that may readily be utilized include, but are not limited to, one or more of the following: direct connection, the Internet, local area network (LAN), wide area network (WAN), Intranet, dial-up network, and wireless network (e.g., infrared, cellular, satellite, radio, or a network using any other wireless communication method). Thus, in practice, the development system 12 and the target system 14 may be connected to one another directly (for example if the target system 14 is at the user's location (or vice versa), or they be geographically separated, as long as they can communicate with one another.
Optionally, if future monitoring and/or management of an implemented target system 14 is desired (for example, to test the target system model developed at the development system 12 as part of the prototyping process), a novel data handling system 18 may be provided as part of, or as an interface to, the target system 14 to ensure guaranteed real-time communication from the target system 14 without any loss of data even during monitoring/management of a complex data system with a massive adapt output. Referring now to
In contrast to previously known systems in which only discrete periodic target system snap-shots were sent to the user, or in which only a single component of a target system could be monitored or managed in real-time, the technique of the present invention enables the target system to continuously generate a real-time data stream limited only by the rated capacity of the RTDB system 856. The RTDB system 856 is the key feature of the data handling system 850, in that, it uses a group of two or more physical or logical buffers (or a combination thereof) to ensure that none of the data arriving from the link 852 is dropped or lost.(unless the entire system completely fails). This is accomplished by recording the data stream in one buffer until a predetermined transfer point is reached in which case the next buffer begins simultaneously recording the data stream. When the fact that the second buffer has started recording is verified, the RTDB system 856 stops recording data in the first buffer, and transmits the data recorded in the buffer before the transfer point and also any data present in its dual recording region which may have been recoded during the time between the predetermined transfer point and the time the next buffer actually started recording the stream. This ensures that even of there is a delay in switching between buffers, not data is lost.
The DHCS 858 may be optionally provided with additional features, for example with diagnostic procedures to test the RTDB system 856 periodically, or immediately preceding or following its use. Another useful novel feature of the DHCS 858 is a data preservation function which enables the DHCS 858 to close buffers that failed a certain amounts of time in a row.
Returning now to
Referring now to
As described above, while an actual real-world target system or device may have many physical components, the RDPI system 10 works with the functional target components (e.g., target components 52, 54) of the target system 50 that are capable of performing one or more actions in response to internal instructions or received commands. The target components themselves can vary from simple to complex. For example, the target component 52 may be a simple temperature sensor, while the target component 54 may be a programmable controller that performs a number of tasks and issues a number of commands to other target systems in response to a particular temperature reading received from the target component 52.
It should be noted that, because a target component (e.g., target component 52) may in itself be a full multi-component system, a particular complex target system may in fact contain a number of other target systems as its components, and those systems may include target systems acting as target components as well, and so on. In fact, this may be a necessary approach when designing very complex systems.
Under certain circumstances, after completion of a prototype design model of a target system 14 and generation of the necessary target system instruction modules, it may not be desirable or feasible, for a variety of reasons, to test these modules in an actual production system. This may be the case if the user designing the system has no access to the actual necessary target Components, or does not wish to utilize production target components, for example, if testing the designed system in production components is dangerous or prohibitively expensive in case of damage to the component due to a design flaw or other type of error. In such cases, it may be desirable to utilize, as a substitute, one or more emulation target components—devices that are capable of emulating the features, outputs, responses to inputs, and other attributes, of the corresponding production target component. For example, an emulation target system may be entirely comprised of emulation target components to test the instruction modules for a designed target system in the safety of a lab or a workshop and at minimal investment.
Furthermore, if the purpose of the prototyping process conducted using the RDPI system 10 is to design and test one or more target components for a particular target system 14, an emulation target system may be specifically configured with the desired production components to be tested, and one or more emulation target components that represent and emulate the production target components in the future final production target system.
Referring now to
As noted above, utilization of the novel RDPI system requires certain information about the target components that are available to the user when designing the target system. For a particular target component, this information can range from very simple list of target capabilities, I/O signals and required protocols to communicate with other target components, to a detailed and comprehensive record that includes additional target information such as rules for using this component with other components, values for physical characteristics, installation requirements, and even the cost or lead time for purchasing the component. This information is preferably stored by the RDPI system 10 and made available to the user during the design/prototyping process. The type, quantity, and scope/detail of target component information may be dependent on the complexity and nature of the system or device being designed and prototyped, on whether a particular target component is a production or emulation component, or on other factors, such as the desired precision, the level of control being made available to the user by superiors, or simply on the availability of the information about a particular target component.
Referring now to
The operational attributes 102, may include, but are not limited to, attributes such as a list of the target component's capabilities (i.e., the list of actions the target component can perform), the capacity of one or more capabilities of the target component (such as data storage memory, processing power, data transmission rate, etc.), the communication protocols and formats usable by the target component, the component's operational parameters (such as specific control/configuration settings, required signals, etc.), I/O data parameters that determine what data or instructions the target component can receive and what outputs it generates, as well as other attributes, such as rules and templates. The operational attributes 102 rules may include restrictions on use with other specific target components, or a requirement of one or more additional target components being connected thereto, or used elsewhere in the target system. The templates may include identification of partial instruction modules available at the development system 12, that when combined with additional information determined after the visual system model is partitioned, can be automatically converted by the system 12 into ready-to-use instruction modules, such as executable code, which may be loaded into the actual target component during implementation.
The installation attributes 104 may include physical characteristics of the target component, such as its dimensions, weight, noise and/or pollution output, resource (fuel, energy, etc.) consumption, or the like, and may also include installation rules such as specific installation and/or safety requirements. Finally, business attributes 106 may include the cost of the target component as well as its availability for use with the target system (lead time, stock status, etc.) to enable the user to incorporate business issues during the prototyping process. Of course, the target attribute record 100 may include other attributes of the above-described or other categories.
It should be noted, that the contents-of the target attribute record 100 may vary greatly in scope and quantity between different target components, but should at least include the minimum attributes necessary for the user to make partition assignment and related decisions during utilization of the RDPI system 10 (as described in greater detail below in connection with
As noted above, in connection with
Nevertheless, for the sake of clarity, and without any limitation from the nomenclature, the core data processing task responsible for enabling the key operations of the inventive RDPI system 10, that is performed by the development system 12, will hereinafter be referred to as a “main program”, while additional data processing tasks will hereinafter be referred to as a “program modules”.
Referring now to
It should be noted, that only those steps necessary or desirable for RDPI system 10 operation are shown. It is contemplated that execution of application programs and program modules as implemented in various types or configurations of development systems 12, may involve numerous conventional processes and steps not shown here because they are not part of the present invention.
Because of numerous abbreviations used in FIGS. 5 to 7, Table 1 below provides a useful definition guide to the terms used in the respective figures.
The process 200 of the present invention begins at a step 202 where the user is provided a with a visual system model of a task control and/or performance system or apparatus, representative of the desired functionality of the target system under development that has been previously designed (by the user or by others) and that is in an interactive graphical format that may be altered or modified by the user and the processes 200-400. Advantageously, the process 200 is applicable to any visual system model that may be created with any form of visual design and/or modeling tools. In fact, optionally, the main program and program modules of the processes 200-400, may even be implemented as “add-ons” to any conventional visual design and/or modeling system or environment, for example as “applets” or “toolboxes.” This enables the user to utilize a familiar design environment, commands, and user-interface, while at the same time taking full advantage of the novel features and capabilities of the RDPI system 10. Optionally, conversion tools may be utilized to convert the visual system model into a format with which the processes 200-400 can interact. For example, if the visual system model was developed on one system using modeling software A, and then transmitted to another user for prototyping using the development system 12 with modeling software B, the user at system 12 can convert the visual model into a format acceptable to software B and begin the prototyping process. This flexibility in working with other available or custom modeling systems and design tools in any environment or operating system with only minor adjustments, makes the novel RDPI system 10 truly platform and vendor-independent.
At a step 204, the user (or the main program) perform the core task of partitioning the visual system model into partitions, each with one or more model elements (e.g. blocks of a block diagram, etc.) suitable for future implementation in various target components of the target system being designed. While one of the key features of the present invention is to give the user an ability to easily define partitions as a matter of their design requirements, optionally, the primary partitioning task and several other steps of the process 200 may be performed automatically by the development system 12. Thus, in one embodiment of the present invention shown as the process 300 in
Referring now to
In some cases, a visual system model may have one or more model elements that are not connected to any other elements or may have a one or more groups of two or more model elements separate from the rest. These “floating” elements represent the portions of the system model which do not have a physical connection to other elements in the target system but that can still interact wit the system in other ways. For example, the model 500 includes two such model elements. For example, one of them is responsible for controlling lighting in the facility where the target system is installed that can affect the model element (ME_DQ) which may be a camera.
The process 300 which begins by performing step 302 until all model elements of the visual system model that are connected to other model elements, have been assigned to a specific partition PART_1 to PART13 N, where N is the total number of partitions in the system. Referring now to
At a step 304, the user selects one or more model elements connected to at least one other model element, and assigns them to a particular partition (PART_X) at a step 306, repeating steps 304, 306, as noted above, until all model elements that were connected to other elements have been assigned to PART_1 to PART_N.
The specific manner in which model elements are assigned to desired partitions may be determined as a matter of design choice or convenience (for example there are many interface and input differences between a development system 12 that is a pocket computer or a system 12 that is a desktop workstation with a large display and key board. Preferably, the assignment step 304 is performed using a graphical user interface (GUI) (not shown) of the output system 24 (e.g., of a monitor), where the model elements may be assigned to each partition with a graphical selection tool, such as a “lasso”, through “clicking” on an element with a pointer and selecting a command in a dialog box, by placing markers on the links connecting the model elements to one another to separate one or more model elements from the rest of the system and form a partition around them, or in any other manner available or convenient to the user. For example, in
At a test 206, it is determined (by the user, or optionally by system 12) if there are any “floating” model elements unassigned to any defined partition. If such elements exist, at a step 208, the user can repeat the partitioning process 300 for these elements or optionally assign them to one or more of the existing partitions as a matter of design choice. The secondary partitioning step is illustrated in
At a step 212, the user, or the system 12, ensure that proper inter-partition communication links (IPC_LINKS) are formed in the TS_MODEL based on the requirements of links and function, communication, and signal flows in the PS_MODEL, for example to ensure that the target components selected at the step 210 can properly work and communicate with one another and any remote system as necessary. At an optional step 214, the system 12 may verify the integrity of the TS_MODEL, for example to ensure that the IPC_LINKS were properly selected at the step 212, and if the results are determined to be unsatisfactory at an optional test 224, proceed to an optional test 206 where the PS_MODEL may be modified by the user, the system 12 returns to the step 210 for re-assignment of target components and modification of the TS_MODEL.
If the results are satisfactory, at this point the user has created a TS_MODEL that may be readily utilized to generate implementation instruction program modules for use in production or emulation target systems, and the process 200 may end at a step 228, where the system 12 outputs the a design system model set (DSM_SET) that includes the verified versions of the PS_MODEL and TS_MODELS. The DSM_SET may then be used by another user at system 12 or at another development system to edit the one or more contents of the DSM_SET, to incorporate the DSM_SET in a larger DSM_SET along with other DSM_SETs, or automatically generate the necessary corresponding executable target system instruction module set (TS_insMSET) for target system implementation.
Alternately, (and preferably in many cases) optional steps 216 and 218 may be performed by the system 12 to automatically generate the necessary TS_insMSET such that the user may readily begin target system implementation without writing a single line of code.
At a step 216, the system 12 automatically generates the necessary executable instruction modules (i.e., the TS_insMSET) based on the target components in the TS_MODEL, but also taking into account the IPC_LINKS and specific requirements embodied in the PS_MODEL that could not be translated directly into the TS_MODEL by the partitioning and target component assignment operations. Any automatic code generation technique capable of meeting the above requirements may be readily utilized at this step to generate the TS_insMSET. However, preferably, a novel inventive code generation process 800 of the present invention, as discussed below in connection with
At an optional step 220 provides the TS_insMSET to the target system (for example, the target system 14 of
Referring now to
At a step 404, the system 12 opens the target attribute records (such as the attribute record 100 of
At a steps 408 to 412, the system 12 analyzes the requirements of unassigned model elements in the visual system model and then assigns specific model elements to optimal approved targets. At a step 414, the system 12 visually indicates the results of the automatic partitioning process to the user as a suggested PS_MODEL, and at an optional step 416 displays to the user at least a portion of the information used by the system 12 at the steps 402 to 412 so that the user can ensure that the system 12 is performing the process 400 correctly and/or optimally. If the user approves the suggested PS_MODEL at a test 418, the system 12 visually indicates PART_1 to PART_N on the visual system model to form PS_MODEL and continues to the step 212 of
As can be seen from the process 200 of FIG. and the processes 300 and 400 of
Referring now to
Because of numerous abbreviations used in
While the process 800 refers to “automatic executable code generation”, it should be understood that the process 800 may be readily utilized to generate any and all instruction sets and related configuration data necessary for enabling the target system executes the received TS_insMSET to implement the desired DSM_SET, and thus to accomplish the full purpose of the RDPI system 10. Thus the process 800 may produce TS_insMSET that includes, without limitation, one or more executable programs, program modules, drivers, program objects, dynamic link libraries, initialization variable values, communication protocol settings, and so on.
In describing the novel process 800, it would be helpful to first define the usage of the terms “templates” and “tokens” with respect to the inventive system. A template is a partially written or completely written code that contains tokens. A token is a piece of identifiable information in the template that need not follow the programming language syntax or semantics. Therefore, the template file cannot be compiled to generate an executable with its default token. A matching substitute token with appropriate information based in part on one or more of the designed system parameters is necessary to make the template “active”—i.e. ready for compilation and conversion into executable code.
In summary, in executing the novel process 800, in steps 802 to 816 of
The various features of the techniques of the present invention also greatly facilitate local or remote monitoring and/or management of a target system, for example, while performing simulations during the design/prototyping process, for remote system troubleshooting, maintenance, or technical support, or when the target system is being used in its ordinary course. While various remote target monitoring/management systems may be used as a matter of design choice or necessity, the development system 12 of the present invention may be advantageously provided with a novel interactive user interface, at its output (i.e. display) system 24 with novel tools and functionality that enable the user to readily design an interactive reconfigurable visual instrument panel for monitoring and/or management of one or more remote target systems or devices. An exemplary visual instrument system design interface 900 is shown in
Accordingly, the inventive system and method enable a user to rapidly move from a visual system model, previously designed using any system modeling application, to a ready for use prototype operational system model, and optionally automatically generate corresponding instruction modules therefrom that may be readily loaded into a desired target system for simulation and/or for actual production use, all without writing a single line of programming code. Moreover, after the prototype system has been designed, the RDPI system of the present invention enables the user to easily make any changes, and refresh the prototype system without having to write code, or re-design the prototype system from scratch, and/or monitor and manage one or more the target systems remotely in real-time.
Thus, while there have been shown and described and pointed out fundamental novel features of the invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.
The present patent application claims priority from the commonly assigned U.S. provisional patent application Ser. No. 60/492,771 entitled “SYSTEM AND METHOD FOR RAPID DESIGN, PROTOTYPING AND IMPLEMENTATION OF DISTRIBUTED SCALABLE ARCHITECTURE FOR TASK CONTROL AND AUTOMATION” filed Aug. 2, 2003.
Number | Date | Country | |
---|---|---|---|
60492771 | Aug 2003 | US |