METHOD AND SYSTEM FOR PROVIDING AN EVENT AUDITING CLIENT SERVER SOFTWARE ARRANGEMENT
A computer system, includes a first input configured for data communication with a network of computers; a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system; a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action where the processor processes an event only in response to the logic approving event action.
This application claims priority to U.S. application Ser. No. 10/247,731, now U.S. Pat. No. 7,322,028, filed Sep. 19, 2002, which claims the benefit of U.S. Provisional Application No. 60/323,575 filed Sep. 19, 2001.
FIELDThis application relates in general to software systems, and in particular to an architecture configured to provide an event auditing client server software arrangement.
BACKGROUNDRecently, a large variety of new computer-based business and manufacturing automation systems have been introduced. New hardware products are coming out at an incredible rate, while new software products are being introduced even more quickly. Although the data analysis, information management and control capabilities brought by these new products have certainly been of great benefit, the products, when installed and configured, seldom meet expectations at anywhere near the projected costs.
One significant problem is constant, never-ending software development. Although the capabilities and features of software packages have increased greatly in the last ten (10) years, the need for programmers and programming services has grown even more rapidly. This is true across various types of software including general packages and those directed towards business and manufacturing automation. The successful system integration of common software packages invariably demands that a great deal of custom code be designed, written and debugged, which is a costly and error-prone activity.
Another emerging and largely unanticipated problem is cyber attacks and other malicious software. Nearly all software systems were designed assuming a benign operating environment in which program operation would proceed without interference. Unfortunately, this assumption is violated nearly every day, especially since 9/11/2001. Cyber attacks are increasing in frequency and in severity and vast majority existing software systems are unable to operate properly under such conditions.
“Stop-gap” measures such as firewalls and anti-virus software have been employed to provide some degree of protection. However, none of these techniques and technologies can provide 100% protection. Firewalls have been successfully breached by teenagers and anti-virus software only works for known virus instances. Software skill sets have migrated across the globe with the natural consequence of a dramatic rise in the sophistication of malicious software used in cyber attacks. This situation is expected to worsen as the software tools and technologies available to the attackers rivals those available to the defenders.
Systems integration firms and end users are devoting an ever-increasing fraction of their budgets to cyber defense, software design, programming and verification. Pedestrian software activities such as configuring a firewall, creating custom menus, formatting dialog boxes, creating custom displays and the like can usually be done via traditional “point-and-click” or by at most editing a script file. Unfortunately, this traditional level of flexibility is woefully inadequate to meet end users' changing needs in a timely and cost-effective manner.
More sophisticated software efforts, such as implementing a new business rule, conforming to new data analysis & reporting regulations, increasing system security, executing a custom menu option, and the like invariably requires significant custom code development in a computer language such as Visual Basic, Visual C or Java. Additionally, to obtain the desired level of end-user functionality, still more custom code must be designed, written and debugged. Further, if the original application was not architected well, it may not even be possible to add this new functionality without extensively rewriting it. The cost of these software design and programming efforts is significant and is considerably greater than the cost of the original out-of-the-box software package.
Nearly all companies maintain Information Technology (IT) departments to handle software installations, upgrades, and custom code development. Significant fractions of companies' operating budgets are allocated to IT departments for these tasks. Companies who are not even in the software business must still make large financial and personnel investments in Information Technology. Thus, both human and capital resources are inefficiently expended on tasks far outside the companies' area of core competency and industry. Cyber defense and software security efforts exacerbate this situation and are beginning to consume a significant fraction of both corporate and government resources.
New operating systems and platform products are introduced into the market at a phenomenal rate. This rapid change often requires application software to be redesigned just to continue to operate with the new computer platform, operating system and/or other application. Thus, many companies' software development efforts and expenses are now driven by external market forces that are completely unrelated to their core business or market. Unfortunately, money spent on this type of software development may not even directly improve productivity, product quality or increase sales. It may even negatively impact profitability and cash flow. The same is true for cyber defense and software security efforts. These activities negatively impact cash flow because they are required for successful business operation yet they do not have direct business benefit in terms of sales, product quality improvement or cost reduction.
A new method and apparatus is thus needed which overcomes the above-mentioned problems and others.
SUMMARYIn accordance with an aspect of this description, a single software application may provide desired functionality to users in a client-server architecture irrespective of the operating system (O/S) operating any computer so architected.
In accordance with another aspect of this description, at least one computer in a client-server architecture may be secure. The server platform and operating system can be configured to implement the “Reference Monitor” software security architecture that is well-known in the art to provide a “Trusted Computing Base” (TCB). The reference monitor may enforce a predetermined (and adjustable) system security policy by controlling the access of every subject or user to every object or rule in the software system. The reference monitor may maintain an access control list (ACL) which determines which subjects or users have access to which objects or rules and the manner of allowed access. Subjects can also be active entities, user processes, etc. while objects can be files, directories, passive data repositories, etc. The reference monitor also may maintain a tamper proof audit trail so that security-related events can be tracked and reported. At least one computer may use this TCB as a platform to help ensure its security.
In accordance with another aspect of this description, the software configuration process corresponds to a software development process that eliminates or significantly reduces the amount of coding required to create a new application or to modify an existing application. The software configuration process may build upon so-called “planar code” permitting introduction of new or revised rules in the process at run-time without need to reference prior code sections.
In accordance with another aspect of this description, the software system may be architected so that it standardizes on multi-vendor-controlled interfaces between major elements—rather than standardizing on vendor-specific, client operating systems, Application Programmer Interfaces (APIs) and other rapidly changing items. Multi-vendor-controlled interfaces are those interfaces that cannot be changed by one software vendor alone. Rather, an interface change requires the express consent of multiple and competing software vendors in the marketplace. Examples of multi-vendor-controlled interfaces/standards are SQL for database access and TCP/IP for network communication. Examples of single-vendor-controlled interfaces/standards are OLE for Object Linking and Embedding for inter-application data object sharing, and NetBUI and NetDDE for network communication, all of which are strictly controlled by Microsoft. Further, these single-vendor-controlled interfaces/standards only apply to Microsoft operating systems and Wintel platforms. Experience has shown that multi-vendor-controlled interfaces/standards have a much longer lifetime than any other type of software “standard” and that they are much more universal in their usage. Standardizing on these types of interfaces—and avoiding the ephemeral, single-vendor-controlled interfaces, is an aspect of the invention to help assure that systems constructed in accord with the teachings herein will have a long operational lifetime.
In accordance with another aspect of this description, the single application that provides the functionality to the end user may be immune to desktop computer viruses or resistant. Authentication logic may be configured to ensure that virus script files, malicious desktop executable images, time bombs and the like cannot authenticate execute on the server or interfere with the proper operation of the single application in any way.
In accordance with another aspect of this description, a method is provided whereby the precise functionality implemented by the single application can be altered or enhanced in real time and delivered to the client machines irrespective of the client machine's O/S.
In accordance with another aspect of this description, the software system can often provide the user-specific functionality without writing new code. The software system may be configured to provide functionality, as determined by rules. Note that this transformation process is one of functionality only. The software system's code itself need not change. The configuration process is flexible enough to change the functionality provided by this single application, including displays, menu options, database tables and structures, data analysis processes, operating rules, reports, graphic objects, and the like. In short, the system can provide nearly any data acquisition, analysis, presentation and archiving functionality by the configuration process.
In accordance with another aspect of this description, the rule based flexibility of the system enables functional behavior that may be configured as an industry-specific software products. The system, when configured with rules “A” may function as industry-specific software product “A”. The same system, when combined with rules “B,” may function as industry-specific software product “B”. In this manner, the system may be configured to service varied industries meeting specific functional requirements.
In accordance with another aspect of this description, the ability of the system to selectively become any of a variety of industry-specific software products may significantly reduce the amount of software development effort and support for this set of software products. Traditionally, one software engineering team and one technical support team would be required for each software product a company makes. A total of “N” software products would require “N” software engineering teams and “N” technical support teams. The system may reduce support needs to only one software engineering team and technical support team since there can be only one application. Systems configured under the teachings herein may enjoy an N-to-1 reduction in the amount of staff and expense needed for software development and technical support.
In accordance with another aspect of this description, a computer may communicate via at least one network and may provide functionality with client computers of any kind, including desktop platforms (PCs), Personal Digital Assistants (PDAs), midrange machines, and the like.
In accordance with another aspect of this description, a system may provide desired functionality to users regardless of the computing environments (e.g. Linux, Windows, Palm and the like), the connection mode to the server (e.g. networked, serial, wireless and the like), and the mix of various client operating systems. The system may provide functionality in part by an enabling architecture which is independent of quickly changing code (client or operating systems) and their associated application program interfaces.
In accordance with another aspect of this description, a system may quickly adapt to new client machine technologies, operating systems, and hardware devices. The system may not require re-design to do this. During a communication process with a client, a translation may convert the communicated items to/from a form that the client machine can understand. This translation may be done dynamically, on-the-fly during any communication with the client. When a new client machine is introduced, the system may only require a translation module or rule set that may convert communicated items to/from a form that the new client understands. This translation need not impact either the operation or the functionality of the single application in any way. Thus, the system may be designed in a client-independent fashion and may not need client-specific items in its architecture. This feature may preserve the substantial investment in software purchase and configuration effort because the system (performing industry-specific functions for an end user) may take nearly immediate advantage of new technology without undue expense and without significant interruption in service. This feature may also provide a significant improvement in the state-of-the-art, which requires that an existing application be redesigned/reworked to work with a new client operating system and/or platform.
In accordance with another aspect of this description, the system can be configured to provide client-specific functionality which can be implemented and maintained by a single support team.
In accordance with another aspect of this description, the single executable application can be configured to act as a standalone software product, or tailored to any desired industry vertical market (e.g., metal forming, pharmaceutical production, chemical process, etc.). The ease of the configuration process and the lack of any code development may make it economically feasible to create entire families of industry-specific and market-specific software products without a corresponding increase in development time, or costly development staff. These new products may employ the same system, differing only in the configuration information or rules.
In accordance with another aspect of this description, a method and system are provided that may provide protection from intentional or unintentional client machine flaws, O/S flaws, errors or omissions, desktop viruses, and other malicious software attacks. This protection may be provided by architecturally segregating, critical functional areas of the application and moving them to protected areas and auditing rules for authorization.
In accordance with another aspect of this description, a method and system are provided that may allow the system to be reconfigured to alter its functionality while it is running and without interrupting its current operation. Further, the altered functionality may be available to all client machines without the need for installing additional software, rebooting or reworking in any way.
Other aspects will occur to those skilled in the art upon reading and understanding the following detailed description.
The teachings here may take physical form in various parts and arrangements of parts, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating exemplary embodiments including the presently preferred embodiment and are not to be construed as limiting the invention. In the accompanying drawings which are incorporated in and constitute a part of the specification, embodiments of the invention are illustrated, which, together with a general description given above, and the detailed description given below, serve to describe the example embodiments of the system and method. It will be appreciated that the illustrated boundaries of elements (e.g. boxes or groups of boxes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that one element may be designed as multiple elements or that multiple elements may be designed as one element. An element shown as an internal component of another element may be implemented as an external component and vice versa.
“Software,” as used herein, includes but is not limited to one or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skill in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like.
“Logic,” as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. For example, based on a desired application or needs, logic may include a software controlled microprocessor, discrete logic like an application specific integrated circuit (ASIC), a programmed logic device, a memory device containing instructions, or the like. Logic may include one or more gates, combinations of gates, or other circuit components. Logic may also be fully embodied as software. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
“Virus,” as used herein includes any type of malicious software targeted toward desktops, personal computers, hand held devices and the like. This includes worms, trojans and time bombs. Viruses can take many forms including executable images and script files. “Virus Immune,” refers to the ability of a system to operate properly despite components of that system being infected or otherwise compromised by a virus. Operating properly includes both protection of data items and operations on those data items.
With reference now to
As shown in
Turning now to
With reference now to
GRAPHICS image 50 contains the “Smart Objects” 54. These Smart Objects 54 comprise graphic images, display objects, interactive analysis objects, action icons, etc. In addition to their data presentation aspects, some Smart Objects may also contain data analysis rules and procedures. For example, one Smart Object could be an “X-bar-R Chart.” The methods and formulas for computing the various statistical measures that comprise the X-bar-R Chart are well-known in the art. These well-known formulas, rules and/or procedures would be a part of the Smart Object called “X-bar-R Chart.” Other Smart Objects could be charts, graphs, spreadsheets, tables, animated objects and the like. GRAPHICS 50 contains these various items, whether or not they are used in a specific application. GRAPHICS 50 may also be a sharable image that is installed once, independent of the number of simultaneous users. VIEW 20 and BUILD 40 use GRAPHICS 50 to display, update and interact with objects, images, and the like. GRAPHICS 50 may include a wide variety of Smart Objects including new Smart Objects, with new and powerful data presentation capabilities, data analysis rules and procedures. Various image modules, such as VIEW 20, DRIVER 30, BUILD 40, GRAPHICS 50, may be resident on server 10 or alternately distributed across the network or multiple servers.
Configuration files 60 may comprise display/screen files, some menus, dialog boxes, help files, special images, some data analysis instructions, some operational rules and the like and are usually created by the BUILD 40 configurator/editor. Alternatively, some of the configuration files may be edited with a normal text editor. This allows non-graphic, text-based devices such as cellular and mobile phones to configure/modify the system—an advantage for supporting systems remotely where, for example, high-speed connections may not be available. Alternatively, some, or all configuration information may be contained in one or more relational databases 70.
Ram-resident database(s) 80 are non-executable images that are sharable, global storage areas for various kinds of real-time data and status information. Preferably, databases 80 are external to the executable application 20 although they may physically reside on the server or be disposed elsewhere on the network.
Relational databases 70 are optional. These can be any relational database such as Oracle, DB-2, Informix, Sybase, etc. Oracle is preferred but not required. These databases may contain historical data, object action rules, some data analysis rules and may include any or all other configuration information. Data communication with any or all of the relational databases occurs through specialized interfaces 72. Input/Output (I/0) handlers/interfaces 74 are also optional and support communication with intelligent instruments, PLCs, DCSs, controllers, foreign databases and the like. These I/O handlers implement the specific communication protocol(s) used by the various external devices and can communicate via a network or a dedicated serial port. These I/O handlers generally take data in ram-resident databases 80 or in relational databases 70 and send it to the particular external device. Conversely, these I/O handlers generally receive data from the external device and place it into either ram-resident databases 80 or in relational databases 70 or both. All communication with external devices, except for user display devices and client machines, is handled by one or more input/output handlers 74 (also called input/output drivers).
In a simple configuration, a system may be composed of four executable images: VIEW 20, DRIVER 30, BUILD 40 and GRAPHICS 50. GRAPHICS 50 and DRIVER 30 can be sharable, re-entrant executable images that are used by all copies of VIEW 20 and BUILD 40. Beneficially, one copy of DRIVER 30 and GRAPHICS 50 may be installed on a given system, even if there are many simultaneous users.
The BUILD 40 image may be used to set up configuration files 60 and optionally relational databases 70 and ram-resident databases 80 so that VIEW 20 can read them and function as the customer-specific application. Although the function changes, VIEW may not change in any way. Rather, VIEW may behave differently, which is really what a new software application is all about—different behavior and/or functionality. This differs from traditional object-oriented programming techniques. In object-oriented programming, significant new functionality in a program is implemented by creating new object(s) and/or re-linking existing ones to form a new executable image. This re-linking can often mean an interruption in program operation which may not be permissible in mission-critical situations. The architecture of this system may avoid this problem because a new executable image may not be created. Significant new functionality can be added simply by changing the configuration information which may be distributed across configuration files 60, relational databases 70 and ram-resident databases 80 and/or the rules that may be separate or embodied therein.
As listed above, a system may include the GRAPHICS, DRIVER, VIEW and BUILD, various configuration files and a database. For each specific application, the same VIEW, GRAPHICS and DRIVER images may be used. In one embodiment, only the configuration files 60, the database 70 (often, but not always) and/or RAM 80 may be altered. This is in sharp contrast to other application creation methods where components, modules, routines, etc. are added/edited/deleted and relinked to create a new executable image.
GRAPHICS 50 may already contain the “Smart Objects” 54 needed. These Smart Objects 54 may comprise graphic images, display objects, interactive analysis objects, action icons, etc. In addition to the data presentation aspects, some Smart Objects may also contain data analysis rules and procedures. If a given application does not need all of the Smart Objects, they may simply not be used, even though they are still present in the software. Thus, GRAPHICS 50 may stay the same regardless of the application. Some Smart Objects 54 may be display objects that control how information is displayed or how it appears to a user. Example Smart Objects may include charts, tables, graphics, numbers, geometric shapes, equipment, images, and the like. Some Smart Objects 54 may include data analysis procedures, rules, etc. within them that may be object-specific and unique. Data analysis rules, procedures and object methods that are common to all Smart Objects need not be included in the Smart Objects 54. Rather, common object methods may be contained in the BUILD 40 module and VIEW 20 module as required. This may save considerable memory and may allow these common object methods to be changed dynamically. Smart Objects 54 are typically static, but may be configured by the BUILD 40 module during the configuration process. They may be configured to do a wide variety of things, including (but not limited to) getting data, performing mathematical analyses, graphic animation, changing in response to external conditions, etc. Each Smart Object may have its own specific set of things that it is able to do. Smart Objects may have different visual display characteristics and data handling attributes may be defined and added to Graphics 50 at any time. Such additional Smart Objects are within the scope of the present disclosure.
Similarly, DRIVER 30 may include the components needed to interface with all client machines and/or display devices. If a given application does not need all of the interface components (because, for instance, the client machines are all of the same type) then the other interface components may simply not used, even though they are still present in the software.
The VIEW utility 20 may be the one executable image that runs on the server computer (HP, Sun, Compaq, Linux, etc.). It may be the only executable image needed for a system. This executable image may be relabeled as required to look like an industry- or market-specific software product, but the actual executable image is still VIEW 20 and is not changed. As previously explained, changing the configuration information can make the VIEW 20 image behave like a completely different product.
To advantageously make one image look and act like a completely different product, the configuration information, contained in either files 60, relational databases 70 or RAM 80 or any combination, or the rules separate from or contained therein may be changed. The configuration information 60, 70, 80 may configure VIEW 20 regarding operation, including what to visual attributes to display, what database tables, fields, datatypes to save to (Data Destination) or retrieve from (Data Source), what data to analyze, how to analyze it, what menus to show, what menu options to execute, what dialog boxes to have, what help files to have, what action(s) to take as a consequence of events such as user input or data value change, what rules to implement, what external/internal procedures to run, etc. So, different configuration information 60, 70, 80 can configure VIEW 20 to act like a different software product, including defining a set of actions and events on which the actions are predicated.
Architecturally, in one embodiment VIEW 20 may consist of two parts I, II. Part I may read the configuration information 60, 70, 80 for the menus, dialog boxes, etc. and sets up the user interface accordingly. Part I may also read the display configuration files as requested by external events, internal or rule events and/or user input (that can also be thought of as an external event). Based upon the display files read by Part I, Part II may gather data, dynamically route it to the proper Smart Object(s) 54, perform some limited analyses (most analyses may be done by each Smart Object), look for desired events and take the corresponding action(s) as required.
Part II may act as a spawned process that executes at a dynamically adjustable rate. Part II may include three components: interactive display and data analysis handler 82; rule handler 84; and icon handler 86. Note that Part II may be a spawned process or may be an internal routine that can be scheduled to execute as needed. This design choice is a function of the capabilities of the particular server's operating system.
The interactive display and data analysis handler 82 may get application data from services specified by the configuration information 60, 70, 80. As further dictated by the configuration information, analysis or computations may be performed and data, results, and the like may be stored in places also specified by the configuration information.
Rule handler 84 may read rules from sources specified in configuration information 60, 70, 80 and execute these rules. These rules may be generic and may specify events, actions, data sources, data operations, data destinations, visual attributes, and data analysis for both application data and computational results. In some applications of the invention, data may be obtained from an external source corresponding to a real-world event. In other applications, writing data to a destination may cause an action to be taken. For example, a “Pressure Safety Rule” could be constructed such that if the pressure in a pipe exceeds a certain threshold, then a safety valve should be opened to release fluid and reduce the pressure. In this example, the communication handler and/or the I/O driver ensures that external pressure data is placed in either the ram database 80 or the relational database(s) 70 or both. The communication handler and/or the I/O driver also ensures that the “Pressure Safety Rule” data output (i.e., opening the safety valve) is sent to the external control device. The specific data formats, data locations, data sampling rates, etc. may be set up as part of the system configuration process using BUILD 40.
Icon handler 86 is a routine that reads a subset of simpler rules contained in the icon Smart Objects 54 in the displays. These icons and the rules they contain may be set up during the configuration process using BUILD 40. Icon handler 86 may read these rules in the icon and execute them. This may result in the icons obtaining information from the configuration information 60, 70, 80 and producing results that may be stored to other locations identifiable through the configuration information or otherwise. Icons can also receive user input directly via mouse clicks, keyboard commands, and dialog boxes. Further, icon information can also be password protected or conform to other authorization schemes. For example, audit logic may be configured to audit received external events and rule events. The audit can include recording event initiation data and selectively approving event action. Exemplary events monitored in this fashion can include thresholds, rates of change, user inputs, time, comparison results, and the like. Representative actions in response to these events include getting particular screens, altering a display, running an internal job, issuing commands to external applications, setting or changing menu options, writing an output or result to a location, performing calculations, and the like.
The BUILD configurator 40 (editor) can be used to set up the configuration data 60, 70, 80 for the VIEW utility 20. In a one embodiment, BUILD may look and feel like a graphics editor. This may make it easy and intuitive to learn. BUILD may produce the configuration data required for the particular application. This configuration information may specify which Smart Objects 54 to use, what each object's data source(s) and destination(s) are, what processing is to be done on the data and how the object's appearance is to be altered as a function of the data and subsequent processing and functionality as discussed above.
For data sources or destinations that are within a relational database 70, the tables, views, fields, data types, data processing, TCP/IP address, account and password, etc. may be set up via BUILD. SQL queries, common “where clauses”, database triggers, and such all may be set up as part of the configuration process via BUILD 40.
For RAM-resident database 80, the data sources, the pointer(s) to the data locations, the data identifiers are also typically set by BUILD 40. Also, data processing rules can be established by BUILD to provide the behavior demanded by the application. These data processing rules are normally saved in the configuration files 60 but can also be placed in the relational database 70.
“Action Icons” are one kind of Smart Object in GRAPHICS 50. These objects may associate an event with an action. Using BUILD 40, an “event” may be defined to observe, for example, a threshold value for a real-time input, a database field value, an alarm condition, or a user input (i.e., a mouse click). Then, an action is defined for whenever this event occurs. For example, the action can be to display a new report/screen, force a real-time output to a new value, write to a table/field in the database, execute another rule, or any of a variety of actions. Configuring an action icon to perform an action may be done through BUILD 40. As is the case with other configuration information, the action icon settings are normally saved in the configuration files 60 but can also be placed in the relational database 70.
In one simplified embodiment, when VIEW 20 executes (i.e., the application is running) it may loop awaiting an event. When one or more of the events occur, VIEW 20 takes the requested action(s). One possible action is to spawn an external (i.e., a foreign) job feeding data or pointers to external applications. For example, if VIEW is configured to act as an environmental monitoring software system, it may have to recalibrate environmental sensors from time to time. Since sensor re-calibration applications are normally supplied by the sensor manufacturer, an action icon might be configured to launch this app whenever a sensor re-calibration is needed. The action icon would not have to know anything specific about the operation of the sensor re-calibration app. It is now apparent that the action icon would only have to know the app identifier, initial parameters to be sent to it and the command string to launch it. This may allow the integration of pre-existing foreign and perhaps incompatible software without having to understand it or link to it at the code level. A command string may be sent to the operating system of the machine where the app to be launched resides. The operating system can interpret the command string and launch the application. This may allow use of pre-existing, specialized applications whenever required. Other variations exist for this idea for using pre-existing, external software without connecting to it at the code level. All such variations are within the scope and spirit of the disclosure.
As an example, if an anomalous condition is detected, VIEW 20 can automatically launch and communicate with a pre-existing application specifically designed to handle the anomalous condition. This powerful feature advantageously employs other software and pre-developed, pre-tested applications. This powerful feature also eliminates unnecessary code development that would traditionally be required to take advantage of external, specialized apps.
Referring to
An previous attempt at compatibility at the code level 94 that provides an object lesson into why compatibility at this level tends to be inconsistent with market place realities is the introduction and evolution of JAVA. The JAVA language was created by Sun Micro-systems and was intended to allow software development in one common language, without regard to the underlying operating system or computer platform. Microsoft obtained a license for the JAVA technology and began inserting proprietary extensions to the JAVA language. These proprietary language extensions later appeared in a Microsoft programming manual called “J++.” These proprietary extensions were not seen by Sun as being compatible with the JAVA language standard. The tension was that Microsoft wanted to push their proprietary language extensions so that programs written in J++ would only work on Microsoft platforms, thus defeating the entire interoperability purpose of JAVA in the first place. This tension eventually resulted in litigation with the practical upshot being that Microsoft has launched a new operating system, Windows XP, which is not JAVA-compatible. This entire language evolutionary process took less than six years. Thus, at the code level, change is quite rapid and “new” and “universal” standards may not be standards at all for very long.
Above code level is the “interface level” 98. This level tends to be multi-vendor controlled and standardized, and thus supported for relatively long periods of time. Examples of software interfaces at this level are TCP/IP, SQL, X-Windows, etc. One aspect of the invention is a software system that provides interoperability and cross-platform functionality at or above the interface level 98. Interfaces have a much longer lifetime—often ten times the lifetime—than operating system APIs and other code-level conventions. Consequently, standardizing at the interface level results in a software system with a much longer lifetime than standardizing at the code level. It is an aspect of this invention to standardize at or above the interface level.
With reference now to
Platform independence is achieved by the client-server architecture. New desktop platforms are treated as clients. They are not used as servers, but may optionally be used as such, depending upon their capabilities. New clients may be added at any time if they are already supported by Driver 30. New client types can be accommodated simply by creating a translation module for the new client type and adding it to Driver 30. The translation modules convert the client-independent interface information used by the single application into a form understood by the new client type. For some client types, an X-Windows emulation performed by Driver 30 would suffice. Web-based clients such as browsers, for example, would use the XML/HTML capabilities of Driver 30. Any number of new client types may be added in this fashion. This architecture allows the inexpensive and non-secure client machines to be used for what they are best suited for: high-performance, interactive data presentation devices that handle user interface tasks and perform some local analysis functions.
Since the desktop, and indeed most client machines, change rapidly, using the desktop as an interactive data display/data entry device with some local analysis capability makes the most design sense. By comparison, changing the server architecture every few months to keep up with desktop changes is very costly, time consuming, error-prone and may not add any value, functionality, reliability, speed, and the like.
Data analysis is rule-based. Data analysis capabilities are built into each display symbol or Smart Object 54 in the symbol library or GRAPHICS 50. Each symbol can be set to appear as desired, perform arithmetic and mathematical computations, send results to a database, etc. Additionally, “non-visible” symbols can be used to do the same operations. For special cases, code can be written to handle analyses that do not fall into a standard category. Generally speaking, a new Smart Object 54 is created and/or additional functionality is added to existing Smart Object(s) 54 to handle such situations.
Data acquisition is done by the server A. It can also be done by external equipment such as sensors sending real-time messages to the server, in any format. Client machines which are used for human-system interaction can be used for data acquisition but are not recommended for this duty. Isolation of the data acquisition, analysis and storage features provide virus-immunity because client machines or other virus-prone devices are isolated from the server and databases. This also preserves the interrupt-driven real-time performance of the data acquisition process. Additionally, many viruses employ scripts or binary code configured to exploit WINTEL based systems. Desirably, these scripts and codes are ignored by systems not employing the WINTEL architecture.
For applications that are not time-critical, acquired data can be transferred to a relational database 70 (
In one embodiment, the application typically uses non-Microsoft platform(s) for the server. These platforms usually have a real-time OS (Compaq's Tru64 UNIX, OpenVMS, HP-UX and Sun Solaris). They are also relatively immune to desktop viruses because they do not run common desktop operating systems and typically do not have the virus-prone MS-software (Outlook, Excel, Explorer, etc.). Such servers are also more secure in their fundamental design and have protection against malicious software that is simply unavailable in common consumer-type desktop platforms. The server architecture and O/S also allows rigorous and effective protection schemes to be incorporated into the application so that the software will continue to operate properly even in the presence of viruses and other malicious software.
With continued reference to
This also keeps desktop-based viruses from hindering system operation. When a desktop is infected, it may cease to function properly (if at all) but it will not in any way affect the operation of the server or system herein disclosed. As an additional security measure, preferably, non-Microsoft operating systems are employed on the server. Such operating systems may include real-time, 64-bit, hyper-reliability, reducing the likelihood of problems such as viruses.
With reference now to
With reference now to
With reference now to
The exemplary networks have been relatively simple to ease comprehension but much larger more complicated networks are possible. Additionally, the examples set forth herein are not mutually exclusive. Thus, combinations and sub-combinations of components of each are within the spirit of the disclosure. The application has been described with reference to several exemplary embodiments. Potential modifications and alterations will occur to others upon a reading and understanding of the specification. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the append claims or the equivalents thereof.
1.0 Rules; 1.1 Overview; 1.1.1 Introduction to Rule-Based Software
IQware™ is rule-based. That means a set of “rules'—rather than formal programming—is used to specific and control the operation of the IQware system, as delivered. This feature is fundamental to the architecture of IQware and is also one of the primary reasons for IQware's tremendous flexibility.
Traditional software applications are developed through design and programming efforts. Nearly all decisions are made at compile time and only a very restricted set of user inputs is allowed at run-time. There is almost no provision for significantly altering the behavior of the delivered system in response to significant changes in the operational environment and/or significant changes in the tasks that the system needs to correctly perform. In such cases, the existing software system must usually be discarded and a new software system must be designed, created and deployed. This is always an expensive undertaking and results in a serious loss of operational capability and continuity.
In contrast, a rule-based system is far more flexible. By design, it can be reconfigured as needed so it can adapt to radical changes in its operational environment. IQware can also adapt to significant changes in the tasks that the system is required to do. This eliminates the need for extremely expensive re-design, re-programming and re-deployment of large-scale software systems. IQware's design also ensures 100% continuity of operations—even while reconfiguration underway. This is a unique advantage of IQware and makes it suitable for all critical infrastructure applications.
1.1.2 Historical Perspective
The need for a rule-based system derived from the necessity of building sufficient flexibility into IQware systems without hard-coding process-flow logic. With the “conditional” rule execution model, operational flexibility is greatly increased. This capability, combined with a sufficiently general definition of events and actions, lets the hard-coded operational rules for the software be fully removed from the source code and performed at run-time, per the rule specifications.
Prior to 7/7/07, ICON_1 was the only “rule carrier” that communicated a rule to both BVC_COMN_ACTION and IQ View. There is one rule per ICON_1 symbol and the rules are screen-specific. This was done for historical reasons because when the software was originally designed, “rule processing” was not considered. It was added later after many of the data structures were already built. Execution-wise, BVC_COMN_ACTION handles the “automatic rules” while IQ View itself handles the “manual rules”; i.e., those rules initiated by mouse clicks.
1.1.3 General Concepts
The Rule Processor (RP) reads operational “rules” from a .BXB or .BXC file. These rules contain the parameters for the events and actions that comprise the rule. Rules are of the form “upon event(s), take action(s)”. Mathematically, rules are of the form “if f(ei) then do g(ai)” where {ei} is the set of allowed events and {ai} is the set of allowed actions. The events and action definitions are sufficiently general to handle a wide variety of “business process flow” requirements. The event-action pairs are orthogonal so that any event(s) can cause any action(s) to be taken—no limitations.
Rules govern the appearance and behavior of data display objects, user interface objects, data gathering operations, database access operations and miscellaneous I/O operations. Not all rules result in something visible occurring on the screen. Rule “classes” that are required to deliver a working system include those in the list below. Note that these categories are for “humans only.” Operationally, there may not be a need for classification:
-
- 1. Object display & screen appearance
- 2. User Interface (UIF) operation
- 3. Database access (Oracle read/write)
- 4. Data collection (from MADT)
- 5. Data analysis (sophisticated calculations)
- 6. Database schema—right now this is only a pointer to the specific tablespace. It is implemented by a unique substring that points to a data file that contains the UID/PWD for the database. This UID/PWD combination puts the user into the table space “preset” in Oracle (or other DB).
- 7. Data archiving
- 8. Object access security & security in general
- 9. Audit trail and content
IQ_BILD supports the graphical setting up of rules. The IQ_BILD_RULE subroutine contains the rule setup DEBs and parameter assignments. The BVC_COMN_FILE subroutine controls the reading/writing of the rules, which (as of Jun. 8, 2007) are embedded as part of the .BXB screen file.
The Rule processor uses the “Reference Monitor” security rules where required for proper enforcement. A portion of the rule parameters contain “O/S permission” parameters, “users allowed” parameters and “access mode” parameters. The security processing is done in one place so that it is easy to test, verify and modify.
It is anticipated that a spreadsheet could be used to specify the rules so the RP will read a CSV file, which is the portable format for a spreadsheet output. It is also expected that rules may be stored in a relational database. Further, rules should also be storable in “IQ private files” (e.g., BXB or BXC files) which will be one of the end products of the IQ Build configuration process.
Additional concepts and approaches are listed below:
1. Each “intelligent object” may have its own private rules that it uses for its own operation. These rules will also be edited by IQ Build. These rules will be screen-specific and only active when that object is displayed on the screen. Other rules will be global. The specification of “local/global” is done in IQ Build.
2. Classes of objects are given below. Note that some functions may be combined and/or they already overlap. That's OK. A certain amount of redundancy in what objects can do provides alternate paths for accomplishing the final software system goals. Also, “sub-objects” may be used to handle lower-level tasks. This implies an object hierarchy. An example this (right now, a current IQware capability) is with graph symbols. These objects use sub-objects to handle graph axes, graph “paper”, graph labels and “plot pen” behavior. Such sub-objects are used for histograms, line graphs, pie charts, pareto charts, x-bar-r charts, etc. Again, this is an existing capability.
a. Data display
b. Data analysis
c. User interface
d. Object-level security
e. File processing (including file conversion to PDF, etc.)
f. Data archiving
g. Tracking and auditing
h. Data output (printing & export)
3. All classes of objects listed above must be device independent and “user I/F independent”. In other words, whatever client communication protocol is used, these objects should operate correctly and not contain any protocol-specific code.
4. Need to create list of user interface objects that we need. Starting point is the list that we have now. Also, the general principle of IQware must apply: the objects must be “very smart”, written in a device-independent manner and in vector form—NEVER pixel! A sample list of essential objects is the following:
a. Submenu item(s)
b. Table
c. Spreadsheet (superset of table)
d. Line graph
e. etc.
5. Current plan is to use Open Source stuff, e.g., WxWidgets (GTK+ etc.) for display objects.
1.1.4 Current Capabilities (prior to 5/1/07)
Here is a list of some current capabilities. This list is not sorted (yet, Oct. 29, 2006) but it will be classified later. It is also expected that this list will be added to as capabilities are discovered and/or added to the architecture.
Currently, there are two main script file types that perform operations on relational database. These files are called SD_VIEW_QUERY_<sub string>.DAT and SD_VIEW_ALTER_<sub string>.DAT. These files cause a sequence of dialog boxes to be presented. The sequence of dialog boxes allows for user input and editing. Based upon the user input, operations are performed on the relational database. Such operations include database queries, database alterations and database updates/inserts.
The rules are stored in various places and they are entered into the IQware through various mechanisms. Some of the rule storage areas, their usage and advantages are highlighted below:
1. Relational database schemes, tables and fields
The rules stored in a relational database typically provide operational parameters to data collection and analysis operations done by the IQware system. The relational database provides a flexible “mailbox” for communication between IQware and outside devices, events, user input, etc.
2. IQware symbol objects, in their respective local data areas
These are created by our IQ Build TM utility which acts similar to a graphics package. IQware symbols are supplied with parameters for database schemas, database access, arithmetic “pre-processing” operations and data display.
3. Flat ASCII files
These simple rule configuration files are used for menu definitions, submenu options, database queries, dialog boxes and similar interface object setup. These setup files allow IQware to be altered and reconfigured remotely by duly authorized and authenticated users. Even better, hand-held devices may be used to completely reconfigure IQware from any remote location. Further, any and all combinations of authentication and encryption may be used to ensure security of the remote connection. IQware works with all available technologies in this area.
4. RAM Resident Data Tables
RAM-resident data tables are used when the rules—or rule parameters—must be rapidly updated, re-read, re-processed and re-executed. This situation occurs primarily in real-time applications such as plant control, plant monitoring and safety-related situations. This feature allows IQware to be configured and used as a real-time control system interface. This is an application that traditional business intelligence software cannot handle. IQware's unique and flexible architecture enables this capability.
Here are some additional notes on current capabilities:
1 . ICON—1 object can invoke rule script files.
2. Script files cause a sequence of DEBs to appear. These DEBs let the user to enter/edit data in various fields. This data entry is fully flexible here in terms of datatypes & formats.
3. The “data fields” within the script files correspond to fields within a data table and within a database schema.
4. At the conclusion of the series of DEBs—after all user input has been acquired—the database is either queried and/or altered (including updates).
5. All user input occurs through ICON—1 which follows security policy.
6. Negative object access results are logged to a security text file for later review. This capability should become rule-based so that it can be changed on the fly.
7. All users share ONE COPY of BVC_GRAPHICS & BVC_DRIVER. This is VERY powerful and allows a LOT of users to coexist in one small RAM space. It is also very convenient for OVMS because it lets OVMS use its own, proven, trusted memory management procedures.
8. IQ Build is not currently linked into Oracle 10g. This allows IQ Build to be used without Oracle installed—very handy. For rules that are stored in the database (if we choose to do that) this will have to change.
9. A minimum number of OVMS APIs are used. Very minimal. So, porting is straightforward. This minimal “intrusion into the O/S space” is another feature of our unique approach.
10. Right now, we control our own code. The only things needed for IQware are a compiler, OVMS and Oracle. That's it. Every “tool” or “thingy” that we introduce makes the “dependency graph” a lot worse (exponentially). This in turn places severe limits on IQ's ability to grow and improve over time. We must not embed anything if we can avoid it.
1.2 IQware's Rule Sources and Types; 1.2.1 Rule Coverage
IQware's rules come from various sources. The rules are informally categorized based upon the areas of IQware's operation(s) that they control. The categories of items that are governed by rules are the following:
1. Object/Screen display
2. User interface object rendering and control
3. Menu object rendering and control
4. Database access
5. Data acquisition
6. Data analysis
7. Report preparation, formatting and output
8. External O/S actions (e.g., run a job, execute command procedure, etc.)
1.2.2 Classes of Rule Elements
Rule elements are grouped into eleven (11) classes. Classes 2 through 11 each require a parameter list for complete specification of the parameters for the rule. The “summary” class does not require a parameter list.
1. Summary (format, ID, location, status, next)
2. Events
3. Actions
4. Data Source
5. Data Destination
6. SQL Source
7. SQL Destination
8. O/S Permissions
9. Access Modes
10. Users Allowed
11. Audit rules
1.2.3 Classes of Data Source and Data Destination Operands
As of 11/7/07, there are six classes of data source (DS) and data destination (DD) operands. These are called INTERNAL, MADT, SCRATCH PAD, EXTERNAL, ORACLE and USER. Each of these classes have at least three operand data types: INTEGER, REAL and CHARACTER. The meanings of these operand classes are listed below.
1. INTERNAL—the operand is contained within the symbol itself, which is a rule symbol or a symbol with rule capabilities. Note that any symbol with RULE capabilities has non-zero values within the symbol descriptor INFO_LIST(16,*). This is the descriptor which contains the pointers to the values and counts of the various rule parameters. See PRM section 8.5 for more details regarding rule parameters.
2. MADT—the operand is contained within the Main Data Table (MADT). The MADT is public to all IQ processes and is generally used only for things that must be shared between IQware users.
3. SCRATCH PAD—the operand is in the scratch pad, which is like the MADT in structure but is process-private. The scratch pad is declared and managed by the rule processor, IQ_RP. The scratch pad is used for items specific to each user's instantiation of IQware.
4. EXTERNAL OBJECT—the operand is contained within another symbol. Two integer identifiers are required to specify the operand. The first one points to the particular symbol and the other points to a location within one of the three symbol parameter lists {IL, RL, TL}.
5. ORACLE—the operand is in the database. In this case, the SQL substrings are concatenated and the desired data item is extracted from the database using the assembled SQL statement.
6. USER—the operand will be supplied as a text string by a user interface (UIF) device/widget. This is only relevant for Data Sources.
More operand classes may be added as deemed necessary.
1.2.4 Structures of Data Source and Data Destination Operands
As of 11/7/07, there are three “structures” of data source (DS) and data destination (DD) operands. These are called SCALARS, VECTORS and ARRAYS. The meanings of these operand types/kinds are listed below.
1. SCALAR—only ONE operand value is required/supplied. A SCALAR DS/DD operand requires three (3) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer.
2. VECTOR—a linear array of operands is required/supplied. A VECTOR DS/DD operand requires four (4) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) a count/maximum number of operands. Note that either (b) or (c) represents the “starting pointer”, depending upon the operand source, specified by item (a). The rule for interpreting the count/maximum is that if the number of actual operands is LESS THAN the number requested, then the count/maximum is set to the actual number of operands retrieved. Conversely, if the number of actual operands retrieved is GREATER THAN the number requested, then the number of operands retrieved is CLAMPED at the count/maximum value.
3. ARRAY (2D)—a two-dimensional array of operands is requested/supplied. A two-dimensional ARRAY DS/DD operand requires five (5) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) the number of rows in the array, e) the number of columns in the array. Note that either (b) or (c) represents the first array item, “array element(1,1)”, depending upon the operand source, specified by item (a). In processing the 2D array, columns are always incremented in the “inner loop”; i.e., they are incremented first. The “rows” are incremented last in the “outer loop.”
4. ARRAY (3D)—a three-dimensional array of operands is requested/supplied. A three-dimensional ARRAY DS/DD operand requires six (6) integer parameters to completely specify it: a) DS/DD source, b) DS/DD Value/Pointer, c) an external array {IL/RL/CL} pointer, d) the number of “rows” in the array, e) the number of “columns in the array, f) the number of “levels” in the array (the z-axis). Note that either (b) or (c) represents the first array item “array element(1,1,1)”, depending upon the operand source, specified by item (a). In processing the 3D array, “levels” are always incremented in the “inner loop”; i.e., they are incremented first. The “columns” are incremented in the “middle loop”. The “rows” are incremented last in the “outer loop.”
5. Higher Dimension Arrays—unsupported as of 11/7/07.
The ARRAY operand definition is expected to be generalized for higher-dimension arrays after 11/7/07.
1.3 Event Definitions; 1.3.1 Detailed Event Descriptions
The allowed set of events and actions provide the raw capabilities for any IQware system. This list is subject to changes and it is expected that additional events and actions will be added as development continues. Also contained in this list are the items required to fully specify each event and each action.
Event List & Description
1. Mouse click on object. This event occurs when the left (or only) mouse button is pressed over the specified RULE object. The RULE object's geometry determines the region of interest for the mouse click.
2. Key press. This event occurs when the “keypress input” matches the desired key sequence, if specified. The ke sequence may be an ASCII byte stream or an XLIB “key symbol code” which is 16-bits.
3. Comparison operation. This event occurs whenever <data object#1><comparison> <data object#2>=TRUE. The data objects are generic and may one of {INTERNAL, MADT, SCRATCH PAD, EXERNAL, ORACLE}. The data types may be one of {INTEGER, REAL, CHARACTER}. The datatypes may be mixed as desired because conversions are automatic. When doing character comparisons, numbers come before letters and letter are in alphabetical order. Thus, “B23”<“C23” and “1234”<“ABCD”.
4. Status of rule “i”. This event occurs when the status bits of rule “i” are set to the desired “bit mask”. As of 8/28/07, the only status bit looked at is bit #2 which signifies “action completed”. The rule status bits are defined in the event parameter table below.
5. Periodically. The event occurs when a “periodic timer” expires. This event causes the specified action to occur on a regular basis at preset intervals.
6. Mouse click in window. This event occurs when the left (or only) mouse button is pressed anywhere within the work window.
7. On Load event. This event occurs when a screen is initially loaded. This condition is sensed by the IQ_RP.FOR internal counter ACTION_LOOP_CTR. This variable is I*8 and is incremented each time the RULE actions are processed. When a new screen is retrieved, this counter is reset to zero.
8. (future)
1.3.2 Event Triggering Options
Events can be triggered in one of three ways: always (the default), periodically (on a regular basis), or once only (upon startup of a new screen). SGB 9/3/07 TBC.
1.3.3 Event Parameters
Here are the definitions of allowed event parameters. These specifications are subject to change. The event code is an integer which specifies the event to be tested. Upon occurrence of this event, the requested action(s) will be performed. In the actual source code, the event parameters are copied to local variable for convenience.
1.4 Action Definitions; 1.4.1 Detailed Action Descriptions
The allowed set of events and actions provide the raw capabilities for any IQware system. This list is subject to changes and it is expected that additional events and actions will be added as development continues.
The allowed actions are described in the numbered list below. Note that most actions will have data source and data destination specifiers. These specifiers will determine where data is obtained and where it is put when the action is completed.
Action List & Description
1. Get A Screen. The screen specified by the data source parameters will be retrieved. This screen retrieval process will “load up” the rule structure with the rules for that screen. The scratch pad area will be cleared out so that “stale data” does not contaminate the new screen, which may use the SP for its operation.
2. Data Transfer. The “operand” specified by the data source (DS) parameters is transferred to the location specified by the data destination (DD) parameters.
3. Use Scrolled Text. The title string will appear on the top of the scrolled text box. The DS will appear within the scrollable window and will be editable. Once edited by the user, the text will be written to the destination specified by the DD parameters.
4. Use File Selection Box. The “pattern string”, directory and selection label are all user-settable per the IQware standard data source (DS) parameters. The pattern string is the “mask” for selecting a group of files, *.FOR or *ABC*.DAT. The directory may be physical of a logical pointer, e.g., IQ$MTM:. The selection label is simply a string that describes what is being selected.
5. Use Prompt Dialog. A dialog box is displayed with some initial text, specified by the data source (DS) parameters. The user can edit this text string and then save it as specified by the data destination (DD) parameters. The DS operand is always converted to a string for editing. The edited string is always converted automatically to the DD data type {I,R,C}.
6. Use Information Dialog. An “information” dialog box is displayed with some message text, specified by the data source (DS) parameters. This string is non-editable and there is no data destination for it.
7. Use Selection Dialog. A list of items is displayed in a scrollable selection dialog widget. The data source (DS) parameters specify the list of items, along with action parameters AV(3) and AV(4). AV(3) is the item list count, or the maximum number of items allowed. AV(4) is the item list “start pointer”, for non-Oracle item lists. If the data source (DS) is oracle, then the SQLS parameters determine the list of items displayed. The selected item from the list is saved as specified by the data destination (DD) parameters. The list item is always converted automatically to the DD data type {I,R,C}.
8. Use Push Button. A Push Button is displayed that activates another rule, specified by the NEXT RULE ID field. The push button also transfers data as specified by the DS and DD parameters.
9. Use DEB. Display a generic DEB with each cell user-specified in IQ_BILD_RULE. Note that each cell can have different DS/DD parameters. The DEB is a container widget which is organized as a rectangular array of user interface widgets and possibly gadgets. Because the DEB requires a large amount of data to completely specify it, the DEB specification information is contained within a binary file. The binary file is “pointed to” by the RULE—1 symbol. The widgets/gadgets supported in the DEB are listed below:
a) IQ_DEB_EMPTY_TYPE—An empty DEB cell. i.e. no discernable UI Widget is displayed.
b) IQ_DEB_SEPARATOR_TYPE—A separator cell. The value for LabelString is optional and InitStringValue is ignored.
c) IQ_DEB_TEXT_FIELD_TYPE—Single-line text field UI Widget.
d) IQ_DEB_SCROLL_TEXT_TYPE—A scrollable text field UI Widget.
e) IQ_DEB_SELECT_BOX_TYPE—A selection box UI Widget.
f) IQ_DEB_FILE_SELECT_BOX_TYPE—A file selection box UI Widget.
10. Display and activate various widget UIF objects (User Interface). These objects include:
a) XmCreateMenuBar
b) XmCreatePopupMenu
c) XmCreatePulldownMenu
d) XmCreateText.
e) XmCreateTextField
f) (Others to be added as required)
11. Display a set of menus and get user input
12. Audit an event. This causes a timestamp, user ID and other relevant information to be saved for later review and reporting.
13. Alter/set object security and access levels.
14. Grant/revoke privileges at the O/S level.
15. Spawn a process (must supply the full process context)
16. Run a job
1.4.2 Action Audit Options; SGB 9/3/07 TBC.
1.4.3 Action Parameters
Here are the definitions of allowed action parameters. These were initially taken from the “ICON—1” symbol, because it is already implemented. These specifications are subject to change. The action code is an integer which specifies the action to be taken. The “Parameters Defined” column details all relevant parameters for the action, where they are stored and what to do with them. Collectively, the list of action parameters uniquely describe the action to be taken.
1.4.4 Action Cleanup options
After an action has been completed, some “cleanup” may be required. This cleanup may involved clearing out the data source(s) for a comparison operation so that it is not re-triggered. This cleanup may require setting/clearing rule status bits, etc. The table below lists the options that are available for rule action cleanup. This “action cleanup word” is a 4-byte BWS and it is stored in AV(2) the second action parameter. Thus, all actions require at least two parameters for complete specification.
1.4.5 Rule Status Bits
Each rule has a 4-byte status word associated with it. This 4-byte integer tracks the status pf the rule and is used for both IQ_RP's “internal housekeeping” as well as for conditioning other events. As an example, Rule “i” can be set to trigger upon the completion of Rule “j”. The table below lists the Rule status bits and their meaning.
1.4.6 Rule Chaining
One rule can be configured to cause the “triggering” (and hence cause the execution) of another rule. For Non-User I/F rules, this happens whenever the “Next Rule ID” field of the RULE—1 symbol is nonzero. For User I/F rules, this happens whenever the “Next Rule ID” field of the RULE—1 symbol is nonzero—AND—the rule's “OK Callback” was activated. If the “Cancel” callback was activated, then no rule chaining occurs. IQ_BILD_RULE allows the setting of this “Next Rule ID” field for each rule action.
1.5 Data Source & Destination Definitions; 1.5.1 Relevant Source Code Modules
The subroutine IQ_DSDD handles the data “gets” and data “puts”. It is called by IQ_RP whenever a data object is required to a) test for an event or b) take an action. It is also called by one or more widget callback routines (e.g., StoreRuleData, okCallbackFunc) that handle the processing of user input. It supports scalars, vectors, 2D-arrays and 3D-arrays (perhaps!).
1.5.2 Data Source & Destination Parameters
The number of data source & destination parameters required for a given rule depends upon the specific rule action code. Each action code is unique and may require more than one data source parameter. The data source parameter codes are listed in the table below. Note that scalars require 3 DS/DD parameters, vectors require 4 DS/DD parameters, 2D-arrays require 5 DS/DD parameters.
1.6 SQL Statement Definitions; 1.6.1SQL Statement Classes
There is only one class of SQL statement: a string. IQware assembles an SQL string at run-time to support fully dynamic database access of any kind. The SQL string is assembled from substrings, which can come from a variety of data sources. These different data sources constitute a different class of substring because the substring access is done differently depending upon the specific data source.
In some cases, it may be desirable to insert a value from another data source into the SQL statement. This is accomplished by using a substring beginning with the @ character. The @ character is followed by a four-letter descriptor which determines which data class will be used. INTL refers to Intemal, MADT refers to the MADT, SCRP refers to the Scratch Pad, and EXTL refers to an External Object. The descriptor is then followed by the data type, enclosed in square brackets. [INT] refers to the integer data type, [REAL] refers to the real data type, and [CHAR] refers to the character data type. Finally, a number enclosed in square brackets determines which position in the data source will be used (equivalent to DS Value/Pointer above). EXTL requires a second number in square brackets (equivalent to DS Ext. Obj. Pointer).
1.6.2 SQL Statement Parameters
SQL parameters are substrings. They are identified, located and retrieved at run-time and then concatenated into one “final” SQL string. The SQL substrings are described by an entry in the RULE_ARGLIST structure. If there are “n” SQL arguments, then there are “n” corresponding entries in the RULE_ARGLIST structure.
Each SQL substring is identified and located based upon the descriptor in the RULE_ARGLIST structure. Each substring may be a literal (i.e., use the substring “as is”) or may be “pointed to” by the “pointer field” of the RULE_ARGLIST entry.
1.7 Identifier Length Limits
OVMS systems using ODS-2 limits file names and UFDs (User File Directories) to 39 characters. OVMS systems version 7.2 and later limit the sum of all characters in all subdirectories of the directory and root components to 512 characters. See the OVMS User's Manual Page 3-3 (part number M-PV5JF-TK, June 2002).
Oracle (Release 10g) limits all object names to 30 bytes. Database names are limited to 8 bytes and database links can be as long as 128 bytes. See page 2-108 of the Oracle SQL Reference, Volume 1.
1.8 Security Issues
1. OVMS security model will be used throughout. Four levels of O/S object access security are defined in OVMS: user, supervisor, executive and kernel.
2. IQ OVMS accounts must be set correctly for process privileges and quotas. This is a simple administrative function. This must be documented in the IQ Setup Manual.
3. IQ security will use OVMS security and will enforce it at the object access level, identical to our current capability. The Reference Monitor architecture will be preserved because it is proven and well-accepted. All user requests for data object access must be validated through the security model. Since all of that is handled by the ICON—1 symbol now, that is easy to do. In the new architecture, a security object will be used to handle this, but that object will be “invisible” per the reference monitor architecture requirements.
4. IQ security will be dynamically alterable. It will support a variety of rule-based security policies. Each IQ object will have a security code and an access code associated with it.
1.9 Proposed Rule Specification and Data Structures; 1.9.1 Structure Summary and Description
RAM-resident rules are stored in several data structures. The structures and records that comprise a rule are listed herein. Note that these structures are flexible in that each records' format may be different. The classes of rule elements are listed below. Each class of rule elements has a “parameter list” that details the parameters' type, value, pointer to its location (if applicable) and length (in bytes). Note that the “pointer” field may be required for variable or nonstandard length fields. This happens when the “argument” (i.e., the field value) is a BLOB, an image, a long text string, etc.
1.9.2 Classes of Rule Elements
Rule elements come in nine (9) classes as of 5/31/07. These classes are listed below. Classes 2 through 8 each require a parameter list for complete specification of the parameters for the rule. The first class “summary” does not require a parameter list.
1. Summary (format, ID, location, status)
2. Events
3. Actions
4. Data Source
5. Data Destination
6. SQL Source
7. SQL Destination
8. O/S Permissions
9. Access Modes
10. Users Allowed
The details of the specific rule fields are listed below:
1. Format Code (I8)—specifier for the structure of the rule. This is used for upward compatibility with “as-yet-unknown-but-anticipated” future expansion.
2. Rule ID (I8)—an integer identifier (and pointer) to a rule.
3. Location (I8)—pointer to the location of the RULE—1 symbol within the screen buffer. Note that as of 7/17/07, RULE—1 is the symbol that “carries”the rule. The RULE data structure is a companion to the RULE—1 symbol.
4. Status flags (I8)—bits that represent the status of the event or action. Examples are event has occurred, action complete, etc.
5. Event Parameter Pointer (I8)—Pointer to the list of event parameters. The event parameters describe the event(s) whose boolean combination of occurrences trigger the rule. The event list also describes the boolean combo of the events that the rule processor will use in deciding whether or not to execute the rule.
6. Event Parameter List (I8/R8)—a list of parameters needed for description of event(s). These may include conditions, thresholds, comparison types, etc. Enough information for the rule processors to issue a Yes/No output for the event occurrence.
7. Action Parameter Pointer (I8)—Pointer to the list of action parameters. The action parameters describe the action(s) executed when the rule is triggered.
8. Action Parameter List (I8/R8)—a list of parameters needed for execution of the action(s). These may include object display parameters and object operation parameters, much like BVC_GRAPHICS arguments are handled currently.
9. Data Source Pointer (I8)—Pointer to the list of data source parameters
10. Data Source Parameter List (I8/R8/BC)—a list of parameters describing the data source and data source type
11. Data Destination Pointer (I8)—Pointer to the list of data destination parameters
12. Data Destination Parameter List (I8/R8/B/C)—a list of parameters describing the data destination and data destination type
13. SQL Source Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
14. SQL Source Statement Parameter List (I8/R8/B/C)—a list of parameters required for the SQL statement assembly. These may include ASCII strings, numbers and pointers to MADT or other data areas (like previous query results, etc.). This list also includes instructions for the assembly of the SQL statement.
15. SQL Destination Statement Pointer (I8)—Pointer to the list of SQL statement parameters.
16. SQL Destination Statement Parameter List (I8/R8/B/C)—a list of parameters required for the SQL statement assembly. These may include ASCII strings, numbers and pointers to MADT or other data areas (like previous query results, etc.). This list also includes instructions for the assembly of the SQL statement.
17. OS permissions Pointer (I8)—pointer to the list of OVMS permissions
18. OS Permissions List (I8/C/B)—a list of OVMS ACL specifier(s) for S,O,G,W; i.e., System, Owner, Group, World
19. Access Mode Pointer (I8)—Pointer to the list of access mode parameters
20. Access Mode Parameter List (I8/B/C)—a list of OVMS specifier(s) for R,W,E,D; i.e., Read Write Execute Delete
21. Users Allowed Pointer (I8)—Pointer to the list of allowed users parameters.
22. Users Allowed Parameter List (B/C)—an ACL of allowed users to access/execute the rule.
1.9.3 Rule Argument List Datatypes
The rule parameters (of any type) are stored within the RULE_ARGLIST structure. This data structure has four fields: TYPE, VALUE, POINTER, LENGTH. The “TYPE” field describes the data type of the rule specific rule parameter.
The type field is a BWS (binary-weighted-sum) with a specific meaning assigned to each bit. The bits dictate the data type. This gives maximum flexibility so that all items that are not mutually exclusive may be used in any Boolean combination.
These TYPE codes apply to all RA(*) parameters except data source (DS) and data destination (DD) parameters. The DS and DD parameters themselves dictate the location of data items and so override the TYPE field.
The “TYPE” field codes and meanings are listed in the table below.
1.9.4 Proposed Rule Structure Declarations (FORTRAN)
In FORTRAN, the various rule structures are given below. Note that the “pointer fields” are pointers into the RULE_PARAMATERS data structure. The “count fields” are the number of entries in the RULE_PARAMETERS structure for each class of rule elements. As an example, here are some pointer value calculations. Note that the storage is in series as listed within the structure.
RULE(1).EPP=1 (first entry in the RULE structure)
In general, the pointers are calculated as follows:
RULE(i).EPP=RULE(i−1).UAP+RULE(i−1).UAC (first free entry after previous rule) 1
RULE(i).EPC=(number of event parameters for rule i) 2
RULE(i).APP=RULE.EPP+RULE.EPC 3
RULE(i).DSP=RULE.APP+RULE.APC 4
RULE(i).DDP=RULE.DSP+RULE.DSC 5
RULE(i).SQLP=RULE.DDP+RULE.DDC 6
RULE(i).OSPP=RULE.SQLP+RULE.SQLC 7
RULE(i).AMP=RULE.OSPP+RULE.OSPC 8
RULE(i).UAP=RULE.AMP+RULE.AMC 9
Note that it might be desirable to have a NULL record between adjacent RULE_ARRAYS that correspond to each rule for sanity checking. This does waste space. Could terminate RULE structure with two consecutive NULL records.
Here is the general case of the parameter list structure. This structure is the same for all classes of rule parameters. This structure is the middle-level hierarchical carrier for all rule parameters. Since some rule parameters may be integer or real scalar arrays, this structure can point to those values as required via the “.p” field. Such scalar arrays are stored in other data structures.
As a reminder, the classes of rule parameters are Events, Actions, Data Source, Data Destination, SQL, O/S Permissions, Access Modes and Users Allowed.
Here is a structure for character arguments. These are of variable and unpredictable lengths. The reason for using this “third level hierarchical storage” is efficiency. The character fields are of variable lengths and so “reserving storage” for them wastes a lot of RAM. This structure allows for variable sizes and the pointers to the beginnings of each character element are mostly computed at compile time.
Here is the structure for the scalar arrays. Note that these scalar arrays hold rule parameters that are sequences of integer, real or character variables. The reason for using this “third level hierarchical storage” is efficiency. If each integer or real object parameter was stored as an element of the RULE_PARAMETERS structure above, each integer/real parameter would require 32 bytes, versus 4 or 8 bytes currently.
Here is the RULE_INFORMATION structure. This is a combination of RULE, RULE_ARGLIST and RULE_CLIST records. This structure should be instantiated in each routine that needs to access the rules.
1.9.5 Proposed Parameter Specification and Structures (RAM Oriented)
All parameters will be given in an ordered list. The start of the list will contain the total number of parameters so the rule processor (RP) knows the where the list ends. The start of the list may also contain the length (in bytes) of the entire list.
The parameters themselves will consist of a “type”, “value”, “pointer” and “length” fields. The list will terminate will a NULL record (i.e., zeros for all its component fields) for integrity verification. The lists may be mapped as integer, real, text, byte as required so that items within the list may take on whatever data type is appropriate, on an as-needed basis.
Generally if the parameter is of real or integer type, then its value will lie within the “value” field of the parameter array. If the parameter is a linear array of integers/reals, then the “pointer” field will point to the starting location of the integer./real parameter array in the “general integer/real array storage area.”
Alternatively, if the parameter is of “text/character” type then the “pointer” field of the parameter array will point to the its location within the “general text/character storage array.”
2.0 Rule Processor Structure & Organization; 2.1 IQ_RP Overview
IQ_RP.FOR is the source file for the rule processor. IQ_RP.COM is the “make file” which is a DCL command procedure that links IQ_RP with all of its component routines as well as the Oracle database.
IQ_RP reads screen files (.BXB) which contain BVC_GRAPHICS symbols. The RULE—1 symbol is the carrier for the rule parameters (Note that the ICON—1 symbol is obsolete as of 9/17/07). One RULE_1 symbol equals one rule. Each rule is characterized by various classes of parameters, as described in the preceding chapter. The RULE—1 symbol is configured within IQ_BILD which uses the subroutine IQ_BILD_RULE to setup events-actions for each rule.
Upon launch, IQ_RP initializes the X-session, opens the startup screen file (*.BXBV) file and implements the rules contained therein. This startup screen file should contain rules that establish global parameters that are deployment-specific.
“Threaded into” IQ_RP's event checking is the use of the XLIB event queue for user events. IQ_RP looks for both user-defined events (through the RULE symbol) and XLIB user I/F events, which appear on the event queue.
IQ_RP is planar code in that its flowchart can be drawn without any crossing lines. IQ_RP consists of two main loops, the “Event Loop” (EL) and the “Action Loop” (AL). The event loop looks for events which are either user interface activities (UIF events) or events defined by the set of rules being executed. The event loop tests for these events and flags those events that have occurred.
2.2 IQ_RP_AST
IQ_RP has an AST (Asynchronous System Trap) routine that scans for periodic events, called IQ_RP_AST. IQ_RP_AST calls a timer routine (IQ_RP_AST_TIMER) which “wakes up” the AST and restarts it as needed. IQ_RP_AST and uses the XLIB procedure “XsendEvent” to put events on the XLIB event queue for processing whenever a periodic event occurs.
2.3 Component Routines
The IQ_RP program uses multiple subroutines and functions. As of 1/20/08 the list of subroutines required by IQ_RP is given in the list below. Note that many of the routines/functions are contained within the IQ_RP.FOR source file.
2.4 Security Checking (SGB TBC)
2.5 Audit Processing
IQ_RP does auditing. This occurs in between the event and action loops. Each “flagged” event may be individually audited as determined by the RULE—1 setup. Each RULE—1 can be configured to rule can be audited to a different degree so that the granularity of audit capability is nearly infinite.
The audit parameters that may be tracked are listed in the table below.
2.6 Display/Screen Management
The rules/conditions for screen redraws are described in this section. Some actions require screen repaints/redraws either explicitly or implicitly. GET SCREEN action causes a redraw of the entire screen. Likewise, any change to symbol geometry requires that all overlapping symbols be redrawn from the bottom layer upward. Layers are numbered from 0 through 15. Alterations to a single symbol that do NOT affect geometry (shape, position, size, orientation) require that only the affected symbol be redrawn.
2.7 Known “Hard Limits”
IQ_RP (and its component routines./functions) has some internally-coded data storage and operand size limitations. Here is the current list of those limitations and where the limitation exists.
2.8 IQ_RP Flowchart
The rule processor flowchart is given below.
Claims
1. A computer system, comprising:
- a first computer comprising: a first input configured for data communication with a network of computers; a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system; a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action; where the processor processes an event only in response to the logic approving event action; and a second computer comprising: a second input configured for data communication with the network of computers; a second processor comprising executable instructions configured to function the second computer as a user interface for content received from the first computer over the network and to generate external events for communication to the first computer over the network.
2. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to effect computer system actions.
3. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to access a data location.
4. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for storing data.
5. The computer system as set forth in claim 3, where the data location comprises a computer-readable medium for retrieving data.
6. The computer system as set forth in claim 1, where at least one of the plurality of rules is configured for processor execution to format visual attributes for communication to and display on the second computer.
7. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for recording event initiation data.
8. The computer system as set forth in claim 1, where the logic comprises user-level discrimination for approving event action.
9. The computer system as set forth in claim 1, where the first processor and the second processor run dissimilar operating systems.
10. A computer system, comprising:
- a first input configured for data communication with a network of computers;
- a computer-readable medium storing processor executable instructions corresponding to a plurality of rules where the plurality of rules control the functionality of the system;
- a first processor configured to receive external events from the network via the first input and configured to receive rule events from the processor executable instructions; and
- logic configured to audit the received external events and rule events, where the audit comprises recording event initiation data and selectively approving event action;
- where the processor processes an event only in response to the logic approving event action.
11. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to effect computer system actions.
12. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to access a data location.
13. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for storing data.
14. The computer system as set forth in claim 12, where the data location comprises a computer-readable medium for retrieving data.
15. The computer system as set forth in claim 10, where at least one of the plurality of rules is configured for processor execution to format visual attributes for communication over the network and display on a second computer.
16. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for recording event initiation data.
17. The computer system as set forth in claim 10, where the logic comprises user-level discrimination for approving event action.
Type: Application
Filed: Jan 22, 2008
Publication Date: Apr 23, 2009
Inventor: Steven G. Belovich (Hinckley, OH)
Application Number: 12/018,017
