Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
A SYSTEM AND A METHOD FOR CONTINUOUS MONITORING AND VERIFICATION OF THE OPERATION OF A MICROCONTROLLER
Document Type and Number:
WIPO Patent Application WO/2019/116368
Kind Code:
A1
Abstract:
The present invention provides a method of monitoring operational controller's for functionality fabrication plants or factories,. The method comprised of: Tapping operational controller's input signals, receiving by an emulator 3rd party inputs that verify the correctness of the operational controller's input signals, comparing the emulator's output is compared with that of the operational controller and analyzing this comparison to ascertain whether there is substantial difference between the two output signals

Inventors:
KRAUZ ACHIEL (IL)
HAREL RAN (IL)
Application Number:
PCT/IL2018/051347
Publication Date:
June 20, 2019
Filing Date:
December 11, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
HALO DIGITAL LTD (IL)
International Classes:
G06F11/00; G05B15/02; G05B19/048; G05B23/00; G06F11/14; G06F21/50; H04L12/26
Foreign References:
US20090138324A12009-05-28
US20110035037A12011-02-10
US20150025689A12015-01-22
Attorney, Agent or Firm:
ZER, Yoram et al. (IL)
Download PDF:
Claims:
CLAIMS

1. A method of monitoring operational controller’s for functionality fabrication plants or factories, which include at least one production modules and sensors, wherein the controller include Firmware and instruction codes , implemented by one or more processors operatively coupled to a non-transitory computer readable storage device, on which are stored modules of instruction code that when executed cause the one or more processors to perform the steps of:

Tapping operational controller’s input signals of production modules within in the plant or factory ;

processing tapped input signals by an emulator to calculate estimated output of the operational controller’s based on the controller firmware and instruction codes;

Comparing the emulator’ s estimated output with the actual operational controller output.

Analyzing the comparison results to identify substantial difference between the two output signals for verifying the correctness of the operational controller’s output signals;

2. The method of the claim 1 , wherein the emulators further receive data from collectors, which include communication, indications and sensory data from non-production modules within the plant or factory, using this data to validate the tapped input signal originated from production module of the implant or factory.

3. The method of the claim 1 , wherein the emulators further receive data from external source outside the implant or factory using this data to validate the tapped input signal originated from production module of the implant or factory.

4. The method of claim 2 wherein the emulator perform the processing and

calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

5. The method of claim 3 wherein the emulator perform the processing and calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

6. The method of claim 1 wherein the comparing includes applying predefined logic to validate the output of the operational controller.

7. The method of claim 1 further comprising the steps of storing the loaded

instruction code, in a dedicated memory space, and performs a predefined set of sanity checks on it and emitting alerts and notifications to administrators upon failure of the said sanity checks.

8. The method of claim 1 wherein the emulator subsystem is encapsulated in a trusted environment, separated from the public domain of the monitored subsystem or of the operational controller.

9. The method of claim 1 wherein , the emulator subsystem is expected to be identical or equivalent to the output of the operational controller in response to identical input

10. The method of claim 1 , wherein the analyzing of the comparison results include at list one of the following:

Evaluating tolerance values for difference in timing and value of the compared output streams.

Evaluating relevancy of detected differences in view of the validity of indicator input.

11. A systems for monitoring operational controller’s for functionality fabrication plants or factories, which include at least one production modules and sensors, wherein the controller include Firmware and instruction codes , comprising one or more non-transitory computer readable storage devices and one or more processors operatively coupled to the storage device(s) on which are stored modules of instruction code executable by the one or more processors, said system comprising at least part of:

Monitoring module for tapping operational controller’s input signals of production modules within in the plat or factory ; An emulator processing device for processing tapped input signals by an emulator to calculate estimated output of the operational controller’s based on the controller firmware and instruction codes;

.verification module for comparing the emulator’s estimated output with the actual operational controller output and analyzing the comparison results to identify substantial difference between the two output signals for verifying the correctness of the operational controller’s output signals;

12. The systems of the claim 11 , wherein the emulators further receive data from collectors, which include communication, indications and sensory data from non-production modules within the plant or factory, using this data to validate the tapped input signal originated from production module of the implant or factory.

13. The systems of the claim 11 , wherein the emulators further receive data from external source outside the implant or factory using this data to validate the tapped input signal originated from production module of the implant or factory.

14. The system of claim 12 wherein the emulator perform the processing and calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

15. The system of claim 13 wherein the emulator perform the processing and calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

16. The systems of claim 11 wherein the comparing includes applying predefined logic to validate the output of the operational controller.

17. The systems of claim 11 wherein the loaded instruction code is stored in a dedicated memory space, and performs a predefined set of sanity checks on it and emitting alerts and notifications to administrators upon failure of the said sanity checks.

18. The system of claim 11 wherein the emulator subsystem is encapsulated in a trusted environment, separated from the public domain of the monitored subsystem or of the operational controller.

19. The system of claim 11 wherein , the emulator subsystem is expected to be identical or equivalent to the output of the operational controller in response to identical input

20. The system of claim 11 , wherein the analyzing of the comparison results include at list one of the following:

Evaluating tolerance values for difference in timing and value of the compared output streams.

Evaluating relevancy of detected differences in view of the validity of indicator input.

Description:
A SYSTEM AND A METHOD FOR CONTINUOUS MONITORING AND VERIFICATION OF THE OPERATION OF A MICROCONTROLLER

FIELD OF THE INVENTION

[0001] The presented invention generally relates to the field of monitoring fabrication plants and factories.

SUMMARY OF THE INVENTION

[0002] The present invention provides a method of monitoring

operational controller’s for functionality fabrication plants or factories, said method comprised of:

Tapping operational controller’s input signals;

Receiving by an emulator 3rd party inputs that verify the correctness of the operational controller’s input signals.

Comparing the emulator’s output is compared with that of the operational controller.

Analyzing this comparison to ascertain whether there is substantial difference between the two output signals;

The present invention provides a method of monitoring operational controller’s for functionality fabrication plants or factories, which include at least one production modules and sensors, wherein the controller include Firmware and instruction codes , implemented by one or more processors operatively coupled to a non-transitory computer readable storage device, on which are stored modules of instruction code that when executed cause the one or more processors to perform the steps of:

Tapping operational controller’s input signals of production modules within in the plant or factory ;

processing tapped input signals by an emulator to calculate estimated output of the operational controller’s based on the controller firmware and instruction codes;

Comparing the emulator’ s estimated output with the actual operational controller output. Analyzing the comparison results to identify substantial difference between the two output signals for verifying the correctness of the operational controller’ s output signal

According to some embodiment of the present invention the emulators further receive data from collectors, which include communication, indications and sensory data from non-production modules within the plant or factory, using this data to validate the tapped input signal originated from production module of the implant or factory.

According to some embodiment of the present invention , wherein the emulators further receive data from external source outside the implant or factory using this data to validate the tapped input signal originated from production module of the implant or factory.

According to some embodiment of the present invention the emulator perform the processing and calculation based on Scenario analysis of the

manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

According to some embodiment of the present invention the emulator perform the processing and calculation based on Scenario analysis of the

manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

According to some embodiment of the present invention the comparing includes applying predefined logic to validate the output of the operational controller.

According to some embodiment of the present invention the method further comprising the steps of storing the loaded instruction code, in a dedicated memory space, and performs a predefined set of sanity checks on it and emitting alerts and notifications to administrators upon failure of the said sanity checks.

According to some embodiment of the present invention the emulator subsystem is encapsulated in a trusted environment, separated from the public domain of the monitored subsystem or of the operational controller. According to some embodiment of the present invention the emulator subsystem is expected to be identical or equivalent to the output of the operational controller in response to identical input

According to some embodiment of the present invention the analyzing of the comparison results include at list one of the following:

Evaluating tolerance values for difference in timing and value of the compared output streams.

Evaluating relevancy of detected differences in view of the validity of indicator input.

The present invention provides a systems for monitoring operational controller’s for functionality fabrication plants or factories, which include at least one production modules and sensors, wherein the controller include Firmware and instruction codes , comprising one or more non-transitory computer readable storage devices and one or more processors operatively coupled to the storage device(s) on which are stored modules of instruction code executable by the one or more processors, said system comprising at least part of:

Monitoring module for tapping operational controller’s input signals of production modules within in the plat or factory ;

An emulator processing device for processing tapped input signals by an emulator to calculate estimated output of the operational controller’s based on the controller firmware and instruction codes;

.verification module for comparing the emulator’s estimated output with the actual operational controller output and analyzing the comparison results to identify substantial difference between the two output signals for verifying the correctness of the operational controller’s output signals; According to some embodiment of the present invention wherein the emulators further receive data from collectors, which include communication, indications and sensory data from non-production modules within the plant or factory, using this data to validate the tapped input signal originated from production module of the implant or factory.

According to some embodiment of the present invention the emulators further receive data from external source outside the implant or factory using this data to validate the tapped input signal originated from production module of the implant or factory.

According to some embodiment of the present invention the emulator perform the processing and calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

According to some embodiment of the present invention the emulator perform the processing and calculation based on Scenario analysis of the manufacturing process in the implant or factory for verifying the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time.

According to some embodiment of the present invention the comparing includes applying predefined logic to validate the output of the operational controller.

According to some embodiment of the present invention the loaded instruction code is stored in a dedicated memory space, and performs a predefined set of sanity checks on it and emitting alerts and notifications to administrators upon failure of the said sanity checks.

According to some embodiment of the present invention the emulator subsystem is encapsulated in a trusted environment, separated from the public domain of the monitored subsystem or of the operational controller.

According to some embodiment of the present invention the emulator subsystem is expected to be identical or equivalent to the output of the operational controller in response to identical input

According to some embodiment of the present invention the analyzing of the comparison results include at list one of the following:

Evaluating tolerance values for difference in timing and value of the compared output streams.

Evaluating relevancy of detected differences in view of the validity of indicator input. DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 presents a schematic, logic block diagram of a system for monitoring and controlling the functionality of an operational controller, according to one embodiment of the present invention.

[0004] Figure 2 presents a flow diagram depicting the normal functionality of the operational controller.

[0005] Figure 3 presents a flow diagram depicting the normal functionality of the emulator subsystem.

[0006] Figure 4 presents a flow diagram depicting the normal functionality of the verification module.

[0007] Figure 5 presents a flow diagram depicting the functionality of the verification module during a boot process, or loading of a new instmction code to the operational controller.

DETAILED DESCRIPTION OF SOME EMBODIMENTS OF THE INVENTION

[0008] Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is applicable to other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

[0009] Following is a table of definitions of the terms used throughout this application.

[0010] The system disclosed in the present invention serves to monitor and verify the operation of a controller by tapping in on the controller’s inputs, and verifying the correctness of its output. The present invention may, for example, be applied to controllers that are installed in fabrication plants and factories, taking input signals from multiple sources, and emitting output control signals to various actuators and instruments.

[0011] According to embodiments of the present invention, verification of the monitored operational controller’s functionality is based upon the following principles:

a. The operational controller’s input signals are tapped in a manner that does not obstruct its normal operation (i.e.: the logic levels and analog values of the operational controller’s inputs are unchanged by their sampling).

b. The tapped input signals are propagated to an emulator, which replaces the operational controller in a separate, safe environment. c. In addition to the tapped input signals, the emulator optionally receives 3 rd party inputs that verify the correctness of the operational controller’s input signals.

d. The emulator’s output is compared with that of the operational controller. This comparison is analyzed to ascertain whether there is substantial difference between the two output signals.

e. The operative controller’s functionality-verification is processed end-to-end, i.e. it encircles all Hardware and Software components of the monitored controller (e.g. Operating system, Instruction code, 10 mapping).

DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 presents a schematic, logic block diagram of the system 10 for fabrication plants and factories, according to one embodiment of the present invention. The system 10 comprises of the following modules and subsystems:

[0013] The operational controller 100 is a computational unit (e.g. Microcontroller, CPU) which monitors and controls the Monitored subsystem. The functionality of the operational controller 100 is monitored and verified by the system of the present invention. Figure 1 depicts the operational controller 100 as schematically comprised of the following logical blocks:

• The Controller input 110: input signals received on the operational controller’s (100) input pins. These input signals may, for example, originate from:

o Control signals from a control interface 400 (e.g. configuration commands from a PC)

o Hardware controls (e.g. RESET, CS signals)

o Input from Indicators 310 within the monitored subsystem 300, i.e. instruments that are monitored by the operational controller 100 (e.g. reading of a digital or analog pressure gauge in a power plant)

• The Controller Hardware and Software 120: This is the combination of

Hardware and Software employed by the operational controller 100 for processing the sard inputs and produced the required output signals. This includes at least one of the following: o The Hardware (e.g. CPU, Memory, Analog-to-Digital converter, etc) that comprises the physical implementation of the operational controller 100,

o The Operating System (OS) which runs on the said hardware o The Firmware and instruction codes that are executed on top the said OS, and

o The mapping of memory and IOs for the said Hardware.

• The Controller output 130: signals that emitted by the operational controller.

Such signals may be emitted in response to the processing of the controller input 110 by the Controller Hardware and Software 120. The Controller output signals 130 are normally propagated to other modules and instruments of the monitored subsystem 300 (e.g. the switch of a kettle which may be turned off in response to a temperature sensor, indicating that the water is near boiling).

[0014] The Controller interface 400 schematic block represents any type of logic interface to the operational controller 100. This interface 400 facilitates the entirety of functions required for the operational controller’s 100 programming, configuration and monitoring. The controller interface 400 may be implemented by any type of computational system (e.g. a dedicated workstation or an online server).

[0015] The monitoring module 70, can be implemented as part of the monitored systems modules or as independent module installed at the plant or the factory associated with the plat or factory subsystems. The monitoring module support tapping the signal or communication lines with the factory or outside the factoring to collect input/output data of the operational controller and any subsystems of the plant or factory.

[0016] The outputs of the controller interface 400 are simultaneously propagated to the operational controller 100, as well as to the emulator subsystem 200. This is to facilitate the comparison of the functionality of the operational controller 100 and the emulator subsystem 200.

[0017] The monitored subsystem 300 schematic block represents any combination of hardware and software that is monitored and controlled by the operational controller 100. A typical configuration of the monitored subsystem 300 will include sensors (e.g. accelerometers on a robotic arm within an assembly line) that propagate their readings to the operational controller 100, and actuators (e.g. motors on same robotic arm) that are controlled by the operational controller 100. [0018] The output emitted by the monitored subsystem 300 block is schematically categorized as originating from one of two types of modules:

• Indicators 310 are modules that emit data, directly indicating a physical state or property of the monitored subsystem. Pertaining to the example of the robotic arm, the indicator data may be the actual reading of a position decoder on a motor incorporated in the robotic arm. The indicators’ 310 output is simultaneously propagated to the operational controller 100, as well as to the emulator subsystem 200. This is to facilitate the comparison of the functionality of the operational controller 100 and the emulator subsystem.

• Collectors 320 are modules that emit“3 rd party” data, implying the correctness of indicator 310 data. Pertaining to the same example, the activity of the robotic arm may be captured on video by a video camera (a collector 320), and thus verifying the position of the robotic arm indicated by the position decoder (indicator 310). The collectors’ 320 output is propagated to the emulator subsystem 200 and the verification module. This is to facilitate the verification of the functionality of the operational controller 100. Optionally the collectors receive data from external resources of third party(800) , such as weather report.

[0019] The emulator subsystem 200 serves to emulate the functionality of the operational controller 100 in response to the same input signals. The emulator subsystem 200 is encapsulated in a trusted environment, separated from the public domain of the monitored subsystem 300 or of the operational controller 100. It is only accessible to authorized personnel (e.g. via the control interface 400), and therefore serves as a reference to the correct, expected function of the operational controller 100.

[0020] The emulator subsystem 200 incorporates at least one of the following modules:

• The scenario analysis module 210 receives the same indicator 310 outputs as the operational controller 100, in addition to collector 320 outputs. It analyzes this information to determine the actions and scenarios that are taking place in the monitored subsystem’s 300 surroundings. The scenario analysis module 210 validates the correctness of the indicator 310 outputs, and may ascertain at least one of the following: o Whether instruments of the monitored subsystem 300 have been tampered with. In this case the scenario analysis module 210 may issue a warning to an administrator.

o Whether the operational controller 100 has been receiving incorrect input data, in which case the scenario analysis module 210 may propagate this information to the verification 500 module.

• The emulator instruction code 220 schematic block represents the entire software that is executed on the emulator system. This includes at least one of the Operating system, Firmware (instruction code) and IO mapping. It is typically identical or equivalent to the software that is assumed to be executed on the operational controller 100. Consequently, the output 230 of the Emulator subsystem is expected to be identical or equivalent to the output of the operational controller 130 in response to identical input.

[0021] The Verification module 500 receives both the output streams of the operational controller 130 and of the emulator 230, and compares them to detect anomalies in the functionality of the operational controller 100.

[0022] In addition, the Verification module 500 receives the output of the Scenario analysis module 210, and is thus able to verify the validity of indicator 310 inputs.

[0023] According to some embodiments, the Verification module 500 is configured to apply rules to the said comparison. These rules include at least one of the following:

• Apply tolerance values for difference in timing and value of the compared output streams.

• Priority and significance of detected differences between the output streams.

• Relevance of detected differences in view of the validity of indicator input.

For example, if the indicator input does not correlate with actions and scenarios that take place in the plant, the relevance of detected differences is considered low.

The verification module may transmit alerts and notification to administrator module 600.

[0024] Figure 2 presents a flow diagram depicting the normal functionality of the operational controller. • The controller 100 receives input signals from the controller interface 400 and the indicators 310 on its input pins. These input signals are tapped, and are also introduced as inputs to the Emulator subsystem 200 (step 1010).

• The controller 100 acts on the input according to its OS and instruction code (step 1020).

• The controller 100 emits output signals on its output pins 130. These output signals are tapped, and are propagated to the verification 500 module (step 1030).

[0025] Figure 3 presents a flow diagram depicting the normal functionality of the emulator subsystem.

• The emulator 200 receives input signals from the controller interface 400, indicators 310 and collectors 320 to the Scenario analysis module 210 (step 2010).

• The Scenario analysis module 210 analyzes the collectors 320 and indicators 310 input. It verifies the authenticity of the indicators inputs, and produces a scenario representing the actual occurrence in the plant in real time (step 2020).

• The emulator 200 applies the emulator instruction code 220 to the said

scenario of occurrence, to produce an emulated output 230 (step 2030).

• The emulated output 230 is propagated to the verification module 500 (step 2040).

[0026] Figure 4 presents a flow diagram depicting the normal functionality of the verification module 500.

• The verification module 500 receives the output of both the operational controller 130 and the emulator subsystem 230 (step 5010).

• The verification module 500 compares the two output streams, and applies predefined logic to validate the output of the operational controller (step 5020).

• The verification module 500 optionally emits alerts and notifications 550 to administrators 600 upon detection of substantial differences between the two output streams (step 5030). [0027] Figure 5 presents a flow diagram depicting the functionality of the verification module 500 during booting, or loading of a new instruction code to the operational controller.

• The verification module 500 taps on the operational controller’s 100 program lines (e.g. JTAG, SPI, I2C) (step 5110).

• The verification module 500 stores the loaded instruction code, in a dedicated memory space, and performs a predefined set of sanity checks on it (step 5120).

• The verification module 500 optionally emits alerts and notifications to

administrators upon failure of the said sanity checks (step 5130).

[0028] The system of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements some or all of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may wherever suitable operate on signals representative of physical objects or substances.

[0029] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions, utilizing terms such as, "processing", "computing", "estimating", "selecting", "ranking", "grading", "calculating", "determining", "generating", "reassessing", "classifying", "generating", "producing", "stereo-matching", "registering", "detecting",

"associating", "superimposing", "obtaining" or the like, refer to the action and/or processes of a computer or computing system, or processor or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories, into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. The term "computer" should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, computing system, communication

devices, processors (e.g. Digital Signal Processor (DSP), Microcontrollers, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.) and other electronic computing devices.

[0030] The present invention may be described, merely for clarity, in terms of terminology specific to particular programming languages, operating systems, browsers, system versions, individual products, and the like. It will be appreciated that this terminology is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention to any particular programming language, operating system, browser, system version, or individual product.

[0031] It is appreciated that software components of the present invention including programs and data may, if desired, be implemented in ROM (Read Only Memory) form including CD-ROMs, EPROMs and EEPROMs, or may be stored in any other suitable typically non-transitory computer-readable medium such as but not limited to disks of various kinds, cards of various kinds and RAMs. Components described herein as software may, alternatively, be implemented wholly or partly in hardware, if desired, using conventional techniques. Conversely, components described herein as hardware may, alternatively, be implemented wholly or partly in software, if desired, using conventional techniques.

[0032] Included in the scope of the present invention, inter alia, are electromagnetic signals carrying computer-readable instructions for performing any or all of the steps of any of the methods shown and described herein, in any suitable order; machine- readable instructions for performing any or all of the steps of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instmctions executable by the machine to perform any or all of the steps of any of the methods shown and described herein, in any suitable order; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the steps of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the steps of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the steps of any of the methods shown and described herein, in any suitable order; electronic devices each including a processor and a cooperating input device and/or output device and operative to perform

in software any steps shown and described herein; information storage devices or physical records, such as disks or hard drives, causing a computer or other device to be configured so as to carry out any or all of the steps of any of the methods shown and described herein, in any suitable order; a program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the steps of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; and hardware which performs any or all of the steps of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non-transitory computer- or machine-readable media.

[0033] Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any step described herein may be computer-implemented. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally include at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

[0034] The scope of the present invention is not limited to structures and functions specifically described herein and is also intended to include devices which have the capacity to yield a structure, or perform a function, described herein, such that even though users of the device may not use the capacity, they are, if they so desire, able to modify the device to obtain the structure or function.

[0035] Features of the present invention which are described in the context of separate embodiments may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment. Also, each system embodiment is intended to include a server-centered "view" or client centered "view", or "view" from any other node of the system, of the entire functionality of the system, computer-readable medium, apparatus, including only those functionalities performed at that server or client or node.