Patent Application
20080028057
To describe the foregoing and other exemplary purposes, aspects, and advantages, we use the following detailed description of an exemplary embodiment of the invention with reference to the drawings, in which:
Referring to
Associated with each self-checkout solution 140-149 are sensors 160, 161 . . . 169, respectively, and actuators 170, 171 . . . 179, respectively. The sensors 160-169 provide a user interface and initiate the event which in this example is a supermarket purchase through a self-checkout terminal. Sensors 160-169 may include a motion detector, a bar code scanner, a radio frequency identification reader, a cash/credit card reader, a weight scale, a touch pad, a microphone, and/or an imaging system. Actuators 170-179 are the devices through which each solution 150-159 responds to user input. The actuators may include a speaker, a display, a conveyor belt, and/or a change dispenser.
For each self-checkout solution, the associated sensors 160-169 and actuators 170-179 interact with the associated embedded computing platform 150-159 through wired or wireless connections, which may include serial, universal serial bus, Firewire, Ethernet, Bluetooth, ZigBee, or other suitable connections. The embedded computing platforms 150-159, also known as deployment platforms, provide the “brains” of each self-checkout solution 140-149 by controlling the input-output (I/O) devices (the sensors and actuators) and by processing the events and data produced by the devices. The embedded computing platforms 150-159 also provide the extension points for deployment and management tools to interact with the POS self-checkout application platform 103. Extension points are used to define new function points for the embedded computing platforms 150-159. Additional plug-ins can plug into these extension points to increase the versatility and scalability of the platforms 150-159.
At least one computing system 101 is used to run the deployment, management, and programming tools and to communicate over a network 102 with the POS self-checkout application platform (or system) 103. The network 102 may be wired or wireless including any of Ethernet, Bluetooth, Wi-Fi, Zigbee, or other networks. The computing system 101 may also interact with other computer systems over a wide-area network 104.
The computing system 101 can be any suitable computing unit comprising basic components such as a processor, system memory, mass storage, and an input/output subsystem connected to the network 102. The system 101 is configured to operate according to an embodiment of the invention. This is accomplished by software tools or by specialized hardware comprising logic for performing the functions of the software tools, such as an Application-Specific Integrated Circuit (ASIC). The network 102 can be a local area or wide area network. We now discuss embodiments where the appropriate configuration is accomplished with software tools.
The behavioral model editor 205 is used to construct a visual system model that represents the behavior of the POS self-checkout application platform 103 of
Once all of the system behavior is specified in the system model, the behavior model editor 205 is used to select one or more groups of components in the model and to designate each group as a deployment unit. Referring again to
The topology model editor 210 is used to construct a visual topology model that represents the logical, hierarchical topology of the POS self-checkout application platform 103. A topology model is constructed by interconnecting architectural components that are accessible through the storage medium 225, where each component represents a node in a system architecture.
At the lowest level of the topology hierarchy, the topology model specifies what types of and how many sensors and actuators are connected to each embedded computing platform 150-159. In this embodiment, this is equivalent to specifying the internal topology of each self-checkout solution 140-149.
At the top level in the topology hierarchy, the topology model specifies which and how each self-checkout solution 140-149 is interconnected to compose the POS self-checkout application platform 103. Each node at the top of the topology hierarchy contains at least one deployment platform 150-159 (e.g., an embedded computing platform). Once the topology model has been specified, it is persistently stored in the storage medium 225 for subsequent reuse.
This hierarchical modeling is extensible. For example, a sensor (or actuator) may represent a composition of sensors (or actuators). Therefore, a sensor (or actuator) may also have a topological structure. Similarly, what we have identified as the system in this embodiment may in fact be only a subsystem in some other embodiment and, hence, only a leaf node in the topological structure.
The mapping algorithm 215 transforms a system model into execution units and then it maps execution units to deployment platforms in a topology model to produce a deployment model. Thus, a deployment model represents a binding of specific behavior to each top-level node in a topology model. The structure of a deployment model has three primary parts: a model identifier, one or more execution units, and one or more mappings.
A model identifier is a unique identifier that distinguishes one deployment model from another. It can be any identifier suitable for indexing and searching, such as a universal resource locator (URL).
An execution unit is a deployment unit made suitable for execution on a targeted deployment platform. Thus, the behavioral components that make up each deployment unit are transformed into executable components. This transformation is typically accomplished through compiling the source code of the behavioral components.
A mapping is a binding of each execution unit to a particular deployment platform of each top-level node in the topology model. As a first approximation, the mapping algorithm performs each binding by making the best match between the topological 2-tuple {number of child nodes, type of child nodes} and the behavioral 2-tuple {number of device adapter components, type of device adapter components}, where the best match may be defined by any suitable metric (e.g., the Euclidean distance between tuples).
If the resources (such as memory, processor speed, and communications interfaces) of each top-level topological node are considered, further refinements on the mapping are possible. If no best match is found for a particular deployment unit, then user intervention, through a visual interface, is required to perform manual mapping.
The mapping algorithm 215 has two primary modes of operation: automatic and semi-automatic. In automatic mode, the algorithm 215 assumes its mapping is correct and passes the deployment model on to the deployment protocol 220. Semi-automatic mode prompts a user to override a plurality of the mappings determined by the algorithm. The mapping algorithm 215 presents a user with this manual override feature through a visual interface. The deployment model is also stored persistently in the storage medium 225.
The deployment protocol 220 uses the deployment model to distribute the respective execution units over the network 102 to the appropriate deployment platforms 150-159 within the POS self-checkout system 103. The deployment platforms 150-159 then load the execution units.
While
To further illustrate the separation of task domains advantage,
The deployment protocol software (not shown) is now distributed between a new software tool, the model execution manager 320, and at least one embedded computing platform 150-159 of the POS self-checkout application platform 103. The model execution manager 320 initiates deployment by transmitting the model identifier over the network 102, to the POS self-checkout application platform 103. The POS self-checkout application platform 103 responds by pulling the execution units, associated with the model identifier, from the storage medium 225 over the network 102. In this embodiment, as in the embodiment referred to in
If the system model is not valid (e.g., a “NO” in step 415), the user redesigns then reconstructs the model. Otherwise, if the system model is valid (e.g., a “YES” in step 415), the user proceeds to the next step, designating the deployment units 416.
The user can designate deployment units using several methods. One method is as follows. Using a mouse or similar input device, the user selects a group of components in the visual system model by drawing a rectangular box around the components. Then by clicking the right mouse button within the model diagram and selecting the appropriate context menu item, the user can designate the components contained in the rectangular region as a deployment unit.
In another exemplary method, the user can select one or more components in the system model diagram one-by-one using the left mouse button and the control key simultaneously. The selected components can then be designated as a deployment unit by using a toolbar button. For one skilled in the art, it should be obvious that other exemplary visual methods of designating deployment units are possible.
The user does not have to assign all components in a system model diagram to a deployment unit. Any component that is not explicitly assigned to a deployment unit is considered an autonomous component. That is, with respect to its deployment, it can be deployed independently of the other components. Once the user has designated the deployment units, then the system model is stored for subsequent use in step 420.
Using the topology model editor 210, a user constructs a visual topology model in step 425. The topology model is constructed by visually interconnecting architectural components. Each architectural component can optionally be annotated with parameters that specify its resources (e.g., memory capacity, processor speed, communication interface) and properties (e.g., network address, symbolic name).
The user validates the topology model architecture in step 430. This can be accomplished via a method of the user's choice, but most often is simply a visual comparison between the logical structure of the model and the physical structure of the system. If a system description file that details the systems properties and resources is available, then the user may optionally import this file to the topology model. Such a file may also serve as a validity check.
If the topology model is not valid (e.g., a “NO” in step 430), the user redesigns then reconstructs the model. Otherwise, if the topology model is valid (e.g., a “YES” in step 430), then the topology model is stored for subsequent use in step 435.
A mapping of a system model and a topology model into a deployment model occurs when the user invokes the mapping algorithm in step 440. In one exemplary method, the user invokes the mapping algorithm by dragging a system model from a workspace view onto the visual topology model using the topology editor. This action invokes the mapping algorithm to transform deployment units into execution units and find the best match between deployment units and autonomous components in the system model to each deployment platform of each top-level node in the topology model.
In automatic mode, the mapping algorithm operates unassisted to generate a deployment model. However, there is one scenario where user assistance may be needed. If the mapping algorithm is unsuccessful in step 445 in finding a match for one or more deployment units or autonomous components, then user intervention is needed to perform manual mapping in step 450.
In semi-automatic mode, the algorithm performs the mapping normally, but after the automatic mapping, the user is prompted to manually override a plurality of mappings. The deployment model is not generated until the user completes the override process. The topology editor may have a toggle button that allows the user to enable or disable automatic mode of the mapping algorithm.
One exemplary method of performing manual mapping is to present the user with a visual palette containing the deployment units of the system model. When the user selects a deployment unit on the palette, the corresponding top-level node it is mapped to in the topology model is highlighted. The user can then override mappings or create new mappings via drag-n-drop of deployment units from the palette to the appropriate top-level node in the topology model. The mapping algorithm then generates the deployment model.
Once the mapping algorithm has generated a deployment model, then the deployment model is stored for subsequent use in step 455.
The user then deploys the execution units of the deployment model over a network in step 460 to the appropriate deployment platforms 150-159 within the POS self-checkout system 103. In one exemplary method, the user performs this action by using a mouse (or other input device) to click the “Deploy” toolbar button on the deployment model view within the topology editor.
In another exemplary method, the user performs this action by using a mouse (or other input device) to open a deployment window from within the topology editor. The deployment window provides the user with a visual interface to select the deployment model, edit the deployments configuration parameters, and then deploy the model.
While the invention has been described in terms of several exemplary embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims. What has been shown and discussed is a highly-simplified depiction of a programmable computer apparatus. Those skilled in the art will appreciate that other low-level components and connections are required in any practical application of a computer apparatus.
Therefore, while there have been described what are presently considered to be preferred embodiments, it will be understood by those skilled in the art that other modifications can be made within the spirit of the invention.
