Verification and validation system for a graphical model

[0001] Technical computing environments are known that present a user, such as a scientist or engineer, with an environment that enables efficient analysis and generation of technical applications. In the MATLAB® technical computing environment, for example, users may perform advanced analyses, visualize data, and develop algorithms. Ideally, a technical computing environment will enable a technical researcher or designer to efficiently and quickly perform tasks such as research and product development.

[0002] Existing technical computing environments may be implemented as or run in conjunction with a graphically-based environment. For example, in one existing graphically-based technical computing environment, models may be built by connecting graphical blocks, where each block may represent an object associated with functionality and/or data. Blocks may be hierarchical in the sense that each block itself may be implemented as one or more blocks. A user may, for instance, view the model at a high level, then select blocks to drill down into the model to see increasing levels of model detail.

[0003] When using graphical modeling tools, it may be desirable to view the state of or monitor particular intermediate points in the model without affecting the operation of the model for the purpose of verification and debugging. For example, it may be desirable to monitor the model for possible error or fault conditions. Existing modeling environments include specialized primitive elements that can be inserted into the model to indicate errors or other exceptional conditions in the model. These specialized verification elements are designed to not influence or affect the operation of the underlying model.

[0014] The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.

[0015] Implementations described herein relate to a technical computing environment in which users may construct graphic models. A verification or consistency check operation may be provided to assist users in verifying that a model is behaving correctly and completely. The verification operation may use substantially any of the primitive elements (e.g., graphical blocks) available to users of the technical computing environment. That is, a user may assemble a verification subsystem with either primitive elements designed specifically for verification or with other more general primitive elements or with other higher level model constructs. The verification operation may guarantee that any primitive elements and/or higher level model constructs within the verification subsystem do not influence the output of the model and do not affect any code generated to implement the model.

[0016] A “technical computing environment,” as the term is used herein, is to be broadly interpreted to include any hardware and/or software based logic that provides a computing environment that allows users to perform tasks related to disciplines, such as, but not limited to, mathematics, science, engineering, medicine, business, etc., more efficiently than if the tasks were performed in another type of computing environment, such as an environment that required the user to develop code in a conventional programming language, such as C++, C, Fortran, Pascal, etc. In one implementation, a technical computing environment may include a dynamically-typed programming language (e.g., the M language) that can be used to express problems and/or solutions in mathematical notations. For example, a technical computing environment may use an array as a basic element, where the array may not require dimensioning. In addition, a technical computing environment may be adapted to perform matrix and/or vector formulations that can be used for data analysis, data visualization, application development, simulation, modeling, algorithm development, etc. These matrix and/or vector formulations may be used in many areas, such as statistics, image processing, signal processing, control design, life sciences modeling, discrete event analysis and/or design, state based analysis and/or design, etc.

[0017] A technical computing environment may further provide mathematical functions and/or graphical tools or blocks (e.g., for creating plots, surfaces, images, volumetric representations, etc.). In one implementation, a technical computing environment may provide these functions and/or tools using toolboxes (e.g., toolboxes for signal processing, image processing, data plotting, parallel processing, etc.). In another implementation, a technical computing environment may provide these functions as block sets. In still another implementation, a technical computing environment may provide these functions in another way, such as via a library, etc.

[0018] A technical computing environment may be implemented as a text-based environment (e.g., MATLAB®; Octave; Python; Comsol Script; MATRIXx from National Instruments; Mathematica from Wolfram Research, Inc.; Mathcad from Mathsoft Engineering & Education Inc.; Maple from Maplesoft; Extend from Imagine That Inc.; Scilab from The French Institution for Research in Computer Science and Control (INRIA); Virtuoso from Cadence; Modelica or Dymola from Dynasim; etc.), a graphically-based environment (e.g., Simulink®, Stateflow®, SimEvents™, etc., by The MathWorks, Inc.; VisSim by Visual Solutions; LabView® by National Instruments; Dymola by Dynasim; SoftWIRE by Measurement Computing; WiT by DALSA Coreco; VEE Pro or SystemVue by Agilent; Vision Program Manager from PPT Vision; Khoros from Khoral Research; Gedae by Gedae, Inc.; Scicos from (INRIA); Virtuoso from Cadence; Rational Rose from IBM; Rhopsody or Tau from Telelogic; Ptolemy from the University of California at Berkeley; aspects of a Unified Modeling Language (UML) or SysML environment; etc.), or another type of environment, such as a hybrid environment that includes one or more of the above-referenced text-based environments and one or more of the above-referenced graphically-based environments.

[0019] FIG. 1 is an exemplary diagram of a system 100 in which concepts described herein may be implemented. The system may include a personal computer or workstation 110. Workstation 110 execute a technical computing environment (TCE) 120 that presents a user with an interface that enables efficient analysis and generation of technical applications. For example, the TCE may provide a numerical and/or symbolic computing environment that allows for matrix manipulation, plotting of functions and data, implementation of algorithms, creation of user interfaces, and/or interfacing with programs in other languages.

[0020] Workstation 110 may operate as a single detached computing device. Alternatively, workstation 110 may be connected to a network 130, such as a local area network (LAN) or wide area network (WAN) such as the Internet. When workstation 110 is connected to a network, TCE 120 may be run by multiple networked computing devices or by one or more remote computing devices. In such an implementation, the TCE may be executed in a distributed manner, such as by executing on multiple computing devices simultaneously. Additionally, in some implementations, the TCE may be executed over a network 130 in a client-server relationship. For example, workstation 110 may act as a client that communicates with, using a web browser, a server that stores and potentially executes the TCE program.

[0021] For example, as shown in FIG. 1, system 100 may include a remote TCE 140 (e.g., a remotely located computing device running a TCE), a remote TCE cluster 150, and/or a TCE service 160. Remote TCE cluster 150 may include multiple computing devices that run TCEs that execute in a distributed or parallel manner. TCE service 160 may include a server computing device that provides a TCE as a remote service. For instance, a TCE may be provided as a web service. The web service may provide access to one or more programs (e.g., TCE) provided by TCE service 160. A “web service,” as the term is used herein, is to be broadly interpreted to include any software application that allows machine-to-machine communications over a network (e.g., a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), such as the Internet, etc.). For example, a web service may communicate with a client (e.g., workstation 110) using an application program interface (API) that the client may access over the network. The web service may exchange Hypertext Markup Language (HTML), Extensible Markup Language (XML), or other types of messages with the client using industry compatible standards (e.g., simple object access protocol (SOAP)) and/or proprietary standards. A web service may further include network services that can be described using industry standard specifications, such as web service definition language (WSDL) and/or proprietary specifications.

[0022] FIG. 2 is a diagram of an exemplary device corresponding to workstation 110. As illustrated, workstation 110 may include a bus 210, a processing unit 220, a main memory 230, a read-only memory (ROM) 240, a storage device 250, an input device 260, an output device 270, and/or a communication interface 280. Bus 210 may include a path that permits communication among the components of workstation 110.

[0023] Processing unit 220 may include a processor, microprocessor, or other types of processing logic that may interpret and execute instructions. Main memory 230 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing unit 220. ROM 240 may include a ROM device or another type of static storage device that may store static information and/or instructions for use by processing unit 220. Storage device 250 may include a magnetic and/or optical recording medium and its corresponding drive.

[0024] Input device 260 may include a mechanism that permits an operator to input information to workstation 110, such as a keyboard, a mouse, a pen, a microphone, voice recognition and/or biometric mechanisms, etc. Output device 270 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 280 may include any transceiver-like mechanism that enables workstation 110 to communicate with other devices and/or systems. For example, communication interface 280 may include mechanisms for communicating with another device or system via a network.

[0025] As will be described in detail below, workstation 110 may perform certain operations in response to processing unit 220 executing software instructions contained in a computer-readable medium, such as main memory 230. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into main memory 230 from another computer-readable medium, such as storage device 250, or from another device via communication interface 280. The software instructions contained in main memory 230 may cause processing unit 220 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0026] The computer-readable medium may particularly include a technical computing environment. The TCE may include any of the features defined above with respect to the term “technical computing environment.” For example, in one implementation, the technical computing environment may include MATLAB® software that provides a variety of mathematical functions and/or graphical tools.

[0027] Although FIG. 2 shows exemplary components of workstation 110, in other implementations, workstation 110 may contain fewer, different, or additional components than depicted in FIG. 2. In still other implementations, one or more components of workstation 110 may perform one or more tasks performed by one or more other components of workstation 110.

[0028] FIG. 3 is a diagram illustrating functional components of a technical computing environment (TCE) 300. As mentioned, TCE 300 may include a program stored on a computer-readable medium, such as main memory 230 or ROM 240 in workstation 110. In other implementations, TCE 300 may be associated with another device separate from workstation 110, and may accessed by workstation 110 via communication interface 280 and a network. In yet other implementations, all or part of TCE 300 may be implemented in hardware.

[0029] TCE 300 may include a TCE language component 310 and a graphical model creation component 320. TCE language component 310 may generally function to implement a technical computing language. TCE language component 310 may, for example, provide an interface that integrates computation, visualization, and programming in a relatively easy-to-use environment where problems and solutions can be expressed in mathematical notation familiar to technical users.

[0030] Graphical model creation component 320 may include software for modeling, simulating, and/or analyzing dynamic systems. Graphical model creation component 320 may, for instance, support linear and nonlinear systems, models in continuous time, sampled time, or a hybrid of the two. Systems modeled with graphical model creation component 320 may be constructed using a graphical interface that allows the user to arrange blocks that represent functionality and/or data. Graphical model creation component 320 may additionally allow users to execute or run the created model and to view and analyze results of the model.

[0031] In general, graphical model creation component 320 can be used to graphically generate designs (i.e., models) that simulate the behavior of the design. The models may be used to facilitate communication, peer-review, and iterative refinement with visual representations that simplify understanding. Graphical model creation component 320 may include specialized blocks that can define error or fault conditions and that can be used to identify design flaws.

[0032] As shown in FIG. 3, graphical model creation component 320 may be used to generate a model 321 that includes one or more verification subsystems 325. Each verification subsystem 325 may include one or more primitive elements and/or higher level model constructs that define desired behavior of the model (i.e., whether the model is behaving correctly and completely). Additionally, graphical model creation component 320 may guarantee that any primitive elements and/or higher level model constructs within a verification subsystem 325 do not influence the output of model 320 and do not affect any code generated to implement model 320. Aspects of graphical model creation component 320 relating to verification subsystems 325 will be described in more detail below.

[0033] Before describing the operation of graphical model creation component 320 in additional detail, it will be helpful to describe an exemplary model generated with graphical model creation component 320.

[0034] FIG. 4 is a diagram illustrating an exemplary graphical interface in which a model may be generated with graphical model creation component 320. The graphical interface may include a model area 400 in which a model (e.g., constructed of blocks) can be built by a user. A library area 450, which will be referred to as “library 450” herein, and a menu bar 460 are also shown as included in the graphical interface.

[0035] Library 450 may include one or more primitive elements or higher level model constructs, called blocks herein, that a user may select and place in model area 400. The blocks included in library 450 may be provided with TCE 300 and/or may be created by users of TCE 300. Library 450 may be organized as a number of sub-libraries that each stores a set of related blocks. As shown in FIG. 4, library 450 may include a commonly used blocks library 455, a continuous library 460, a sources library 465, and a model verification library 470. Sources library 465 and model verification library 470 are shown in an expanded view such that the blocks contained in these libraries are illustrated.

[0036] Sources library 465, for instance, may include a constant block 466 and a clock block 467. Constant block 466 may be a block designed to output a signal having a constant, user-settable value. Clock block 467 may be a block designed to output a clock signal.

[0037] Model verification library 470 may include a number of model verification blocks that may be specifically designed to provide verification for a model. Three exemplary model verification blocks are illustrated in FIG. 4. These blocks include: a check static lower bound block 471, a check static upper bound block 472, and a scope block 473. Check static lower bound block 471 and check static upper bound block 472 may be used to monitor whether a signal level at a particular node in a model goes below (block 471) or above (block 472) a preset level. These blocks may, for example, generate an error condition or a log event if this happens. Scope block 473 may allow a user to graphically plot the signal(s) at a particular node in a model.

[0038] Menu bar 460 may include a number of graphically selectable menu options, such as a file menu option 461, an edit menu option 462, a view menu option 463, a simulation menu option 464, and a verification menu option 465. Each menu option may correspond to, for example, a user-selectable command or a sub-menu with additional commands.

[0039] Consistent with aspects described herein, verification menu option 465 may be used to control graphical model creation component 320 to perform operations relating to verification. For example, a user may use verification menu option 465 to select one or more blocks for inclusion in a verification subsystem. Blocks included in a verification subsystem may be automatically analyzed by graphical model creation component 320 (FIG. 3) to ensure that the blocks do not influence the output of a model or affect any code generated when implementing the model. In alternate implementations, other methods, such as a right-click context menu or a block in library 450, may be used to interact with graphical model creation component 320.

[0040] In the example of FIG. 4, model area 400 includes a model simulating the behavior of a ball dropped from an initial height. The model may include a number of blocks 405, 410, 415, 420, and 425. Each of blocks 405-425 may define elements from which a model may be built. A block may represent functionality and/or data and may be defined using any of a number of possible programming languages. A block may also itself be defined by one or more other blocks.

[0041] The model shown in FIG. 4 may have been generated by a user placing each of blocks 405 through 425 in model area 400, connecting inputs and outputs of the blocks to create logical connections between the blocks, and configuring parameters relating to the blocks.

[0042] As shown in FIG. 4, a constant block 405 may be used to represent the constant acceleration due to gravity (−9.81). Block 415 may represent the initial velocity of the ball (e.g., 15 meters/second in this example). Lines may be connected from blocks 405 and 415 to block 410, indicating that the outputs of blocks 405 and 415 may be inputs to block 410. Blocks 410 and 425 may be integrator blocks which have been labeled “velocity” and “position,” respectively, and the output of these blocks may represent the velocity and position of the ball. The output of block 420 may be input to block 415 and the output of block 425 may be fed back to block 410. A second output of block 410 may be input to gain block 420, which is labeled as ball elasticity. The output of gain block 420 may modify initial velocity block 415.

[0043] A user, after constructing the model represented by blocks 405 through 425, may instruct, via simulate menu option 464, graphical model creation component 320 to simulate (e.g., run) the model, which may cause graphical model creation component 320 to implement the system defined by blocks 405 through 425. The user may wish to validate or verify the operation of the model using graphical model creation component 320. For example, the user may place an instance of scope block 473 in model area 400 and may connect an input of the scope block to an output of one of blocks 405 through 425. Scope block 473 may act as a virtual oscilloscope that may allow the user to visualize the signal to which it is connected.

[0044] As mentioned previously, verification subsystems 325 may be used by TCE 300 to verify the correct operation or behavior of a model. A user may, for instance, design a verification system to test one or more aspects of the model. For example, a verification subsystem may be used to monitor whether certain signals within a model exceed threshold values or take on error conditions. In general, any of a number of known techniques can be used to verify correct behavior of a model.

[0045] Additionally, consistent with aspects described herein, TCE 300 may ensure that one or more designated verification primitives or other model blocks, when placed in a designated verification subsystem 325, do not influence the output of the model. FIG. 5 is a flow chart illustrating the operation of graphical model creation component 320 in the context of verification subsystems 325.

[0046] A user may design a model using graphical creation component 320 (act 510). As discussed above, in one implementation, the user may design the model by manipulating blocks (i.e., primitive model elements or constructs of multiple primitive model elements) in a graphical interface. At some point, such as either during creation or after creation of the model, the user may activate via, for example, verification menu option 465, a verification function of graphical model creation component 320 (act 520). In one implementation, when selected, the verification function may allow the user to select blocks that are to be grouped together or otherwise associated with one another as a group of blocks (act 530) that define a verification subsystem that will be used to verify correct behavior of the model. For example, graphical model creation component 320 may allow the user to select multiple blocks by clicking on each block using a mouse. As each block is selected, it may be added to the verification subsystem. Similarly, a user may remove blocks from a verification subsystem by, for example, selecting one or more blocks in a remove operation. In this manner, the user can create verification subsystems that include arbitrary groupings of blocks. Act 530 will be described in more detail below with reference to FIG. 7.

[0047] The blocks selected by the user as being included in a verification subsystem may generally include any block in the model. Blocks that are designed specifically as verification and validation blocks or primitives, such as blocks in model verification library 470 may be added to the verification subsystem. Additionally, blocks that are not specifically designed for verification and validation, such as blocks in continuous library 460 and sources library 465, may be similarly added to the verification subsystem.

[0048] FIG. 6 is a diagram of an exemplary user interface illustrating a verification subsystem 600 defined for a model. The model in the example of FIG. 6 is identical to that shown in FIG. 4, except that a verification subsystem 600 is also included. Verification subsystem 600 may include a check static lower bound block 610 and a clock block 620. Assume that the user, after or during creation of the model, decided to add check static lower bound block 610 and clock block 620. The user may add these blocks to the model and configure parameters for these blocks. The user may then, via, for example, verification menu option 465, indicate that these blocks are to be included in verification subsystem 600. The fact that a number of blocks correspond to a particular verification subsystem may be graphically shown to the user. For example, as shown in FIG. 6, a dashed box surrounds static lower bound block 610 and clock block 620. Other methods for graphically showing that blocks correspond to a particular verification subsystem could also be used. For example, blocks in a particular verification subsystem may be given a distinctive color, font, or other visual indicator.

[0049] FIG. 7 is a diagram of an exemplary user interface illustrating verification subsystems 600 and 700 defined for a model. In this example, the model illustrated is identical to that shown in FIG. 6, except that an additional verification subsystem 700 is included. Verification subsystem 700 may include an integrator block 710, a gain block 720, and a scope block 730. Verification subsystem 700 may be handled by graphical model creation component 320 as a verification subsystem distinct from verification subsystem 600.

[0050] Referring back to FIG. 5, graphical model creation component 320 may ensure that the contents of a verification subsystem do not influence the output of the model (act 540). Graphical model creation component 320 may, in response to a user command, generate output code that implements a model. Graphical model creation component 320 may, in some implementations, additionally ensure that the contents of a verification subsystem do not influence the output code.

[0051] Graphical model creation component 320 may check to ensure that the contents of a verification subsystem do not influence the output of the model at a number of different possible times. For example, graphical model creation component 320 may perform this check every time a change is made to the model (e.g., a block is added or modified). Additionally or alternatively, graphical model creation component 320 may make this check periodically or in response to an explicit user command. Techniques for verifying that a block or section of code does not influence other parts of a system are known and will not be described further herein.

[0052] In some implementations, graphical model creation component 320 may visually indicate the completeness of a verification activity for a verification subsystem. For example, a verification subsystem may display a checkmark or other graphical indicator, or may change some other aspect of its visual appearance to indicate completion of a verification activity. FIG. 8 is a diagram of an exemplary user interface illustrating a verification subsystem 600 defined for a model. The model shown in FIG. 8 is identical to that shown in FIG. 6, except that verification subsystem 600 is shown as including a checkmark 810. Checkmark 810 may indicate that a verification activity is complete for verification subsystem 600.

[0053] In still other implementations, a verification subsystem may, at certain times, be visually hidden or be displayed with a reduced visibility to the user. For example, the user may explicitly select that a verification subsystem be hidden or shown with reduced visibility. In other implementations, graphical model creation component 320 may include an “auto-hide” feature in which the verification subsystem may be hidden from user view if graphical model creation component 320 determines that the user is performing activities not related to verification and validation. FIG. 9 is a diagram of an exemplary user interface illustrating a verification subsystem 900 defined for a model. Assume that verification subsystem 900 is defined identically to verification subsystem 600. In this example, however, verification subsystem 900 is shown in a “minimized” (reduced visibility mode). The user may switch back to the non-minimized view by, for example, selecting a portion of the icon that represents verification subsystem 900.

[0054] In some situations, graphical model creation component 320 may, in performing a verification activity for a verification subsystem, determine that one or more blocks in the verification subsystem affect the output of the model. For example, a block in the verification subsystem may attempt to write a result to a block outside of the verification subsystem. In these situations, graphical model creation component 320 may generate and output an error condition or otherwise inform the user of the block that is inappropriately writing to the model. Additionally, in some implementations, graphical model creation component 320 may allow a user to enable and disable blocks contained in the verification subsystems. For example, a user may configure certain blocks within a verification subsystem to be automatically disabled based on the complexity or completeness of the verification being performed.

[0055] As described above, verification subsystems may be defined in a model that operate as a container that guarantees objects in the container do not affect the behavior of a model or affect the code generated to implement the model. Arbitrary objects available in graphical model creation component 320 may be placed in the verification subsystem. In this manner, flexibility and the full programming power of the technical computing environment can be made available to the user when designing verification subsystems to determine whether a model is functioning correctly. A verification subsystem may itself be thus treated as a model.

[0056] Graphical model creation component 320 may allow users to define interfaces for models. The interfaces generally may define the signals or variables output from or required by (i.e., consumed) a model.

[0057] FIG. 10 is a diagram conceptually illustrating interactions between a verification interface of a model and a requirements interface of a verification subsystem. A user may define a model 1010 and a verification subsystem 1020. The verification subsystem may itself be a model. Interfaces may also be defined for model 1010 and verification subsystem 1020, labeled as verification interface 1015 and requirements interface 1025, respectively.

[0058] Verification interface 1015 may specify variables and/or signals that are included in the interface. Conceptually, verification interface 1015 may be thought of as defining test points or pads on model 1010 at which signals or variables are to be monitored. A verification interface may be defined by, for example, a combination of: port names, data names, logging names, model hierarchy, and/or explicit tagging.

[0059] Although verification interface 1015 is shown as corresponding to a single model 1010 in FIG. 10, a verification interface for a model may correspond to an interface for multiple models. That is, multiple models may contribute to a verification interface. Further, models can define a subset or a superset of another model's verification interface.

[0060] In some implementations, verification interface 1015 may only be available when model 1010 is being used for certain purposes. For instance, optimizations or other operations may hide or eliminate elements of verification interface 1015.

[0061] Verification subsystem 1020 may be designed as a requirements model that may consume the data produced by model 1010. Requirements interface 1025 may be defined to specify the data required by verification subsystem 1020. Requirements interface 1025 may have a purely read-only view of model 1010.

[0062] Based on the explicit definition of verification interface 1015 and requirements interface 1025, graphical model creation component 320 may automatically determine whether model 1010 can be tested by verification subsystem 1020. More specifically, model 1010 and verification subsystem 1020 may be determined to be compatible with one another when verification interface 1015 defines the interface or a superset of the interface of requirements interface 1025. A requirements model defined by verification subsystem 1020 may be compatible with any design model in which the interface for the model is compatible with the interface for the verification subsystem. In this situation, graphical model creation component 320 may analyze the design model, based on the requirements model, to obtain requirements results for the user. Also, there may be a many to many relationship between models 1010 and corresponding verification subsystems.

[0063] In some implementations, requirements interface 1025 may define default values for certain interface inputs. This may have the effect of expanding the set of compatible verification interfaces.

[0064] A verification tool in a graphical model creation component was described herein that may provide for the full expressive power of the graphical modeling system to be used to define error or exceptional conditions without adverse affects on the ultimate implementation of the model.

[0065] The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention.

[0066] For example, while a series of acts has been described with regard to FIG. 5, the order of the acts may be modified in other implementations. Further, non-dependent acts may be performed in parallel.

[0067] Also, the term “user” has been used herein. The term “user” is intended to be broadly interpreted to include a workstation or a user of a workstation.

[0068] It will be apparent that embodiments, as described herein, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that one would be able to design software and control hardware to implement the embodiments based on the description herein.

[0069] Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as an application specific integrated circuit or a field programmable gate array, software, or a combination of hardware and software.

[0070] No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.