The Savoy WebEngine Computing Environment
The Savoy WebEngine is a networked
computer system that provides higher-level operating system services for
managing objects in a real-world environment.
Objects are cast into a common framework referred to as ‘Devices’. This framework provides the environment in
which Devices can interact. Device interaction is controlled by the
execution of a rule-based computing element, which permits device states to be
compared, combined and controlled.
The WebEngine is designed to operate
on networks of computers and is a
combination of a client/server as well as peer-peer system that can be run all
in a single machine, or across a network. Network operation can include local
area Ethernet, dial-up modems, or Internet.
The WebEngine system can be applied
to a broad base of applications that require the control and coordination of
persistent Devices. Devices include a
wide variety of categories such as communication devices (faxes, telephones,
pagers, email), environmental devices (security systems, lighting, heating),
computer-related devices, Internet sites, and more, within a home, a small
business, a factory, or combinations of these connected across the Internet.
Savoy WebEngine™ - a
Networked Control System for Devices
The Savoy WebEngine utilizes advanced concepts in object
design and networking to provide a comprehensive, network based environment for
the coordination and control of Device objects.
Let’s examine some of the characteristics of this system and how they
compare with conventional approaches.
Characteristics of Devices:
Containment - a Device is a component that encapsulates both
data and programs required to support the device’s behavior. Devices have
methods that can affect its state, and Devices have events generated from
activity within the object.
Properties - data parameters that describe the state and
activity of a device.
Persistence - once
created, devices exist beyond the duration of any single program or computer
activity.
Accessibility - Devices exist in a global network-wide
name-space and are accessible from any location within that name-space.
Mobility - certain devices can move from one location to
another.
Characteristics of Device Development:
Derivation (Inheritance) - Devices are derived from a root
class that provides the minimal essential behavior required for the system
(Assert, Evaluate TBD)
Composition - Devices can be combined to provide higher
levels of behavior
Scalability - Devices can be added to the system dynamically
in a manner that does not create disproportionately greater complexity.
Characteristics of
the Device-based Networked Control System
Rule-based Control Logic - A rule is the fundamental
computational element. It performs
Evaluation functions of Devices, and Boolean logic tests on the states of
devices which results in conditional changes in Device state.
Normalized Device Interaction - Base class of all Devices
provides methods required to perform elementary rule calculations.
Ubiquitous Architecture - Scalable architecture permitting
server functions to run in Internet servers, dedicated PCs, as a background
task in an office PC, in an embedded Windows/CE processor, and in a Java
VM. All implementations coordinate peer
to peer using TCP/IP protocols.
Networked Name-Space - All interconnected servers exchange
Device context, creating proxies for remote devices, and permitting rule
operations to be performed on the network global set of devices.
Adaptability - The set of supported devices can be expanded
by the development of additional Type Managers, which can be incrementally
installed in a system without interruption of service. Type Managers can be designed to support
practically any new Device, permitting device specific properties and
assertions which are automatically applied to the rule logic.
Scalability - The concept of a scoped name-space is applied
to device name propagation across the network of interconnected servers. By managing the scopes of name spaces, the
device interaction is controlled, permitting very large systems to expand
linearly.
As a networked control system for devices, the WebEngine
represents a computing paradigm which can be compared to conventional computer
systems by way of analogy:
Conventional system
Savoy WebEngine
It is generally assumed that all devices endowed with
computers will somehow be able to communicate with each other – the industry
has a sufficient number of proposed ways to do this [CEBUS, home network LANS,
JINI, etc. ]. Beyond how
they will communicate, however, is the question of what they will
communicate. That is, what is the
logic, or set of algorithms, that determine overall behavior of a complex
system of devices?
In some cases, a device may require specific services of
another device. For example, an HVAC
(Heating, Ventilation, and Air Conditioning) unit requires the specific
services of a thermostat, a requirement designed into these particular
devices. But suppose we wish to extend
the ‘design’ of a device to provide an unforeseen interaction, like having your
thermostat interact with a security system (reducing the temperature while
away)? For this purpose, we need a way
to extend the logic of a device.
In object-oriented computer languages (e.g., C++, Java),
extending the design of an object is done by deriving another object from it
and then adding methods to implement the extensions. However, if we added the extension as object
methods, both participating devices would have to be ‘designed’ for the
interaction; e.g., the security system
would have to ‘know’ about thermostats.
We have a stricter requirement: any device should be able to dynamically
connect to any other device without any knowledge of their partners. To achieve this, we must impose some strict
conformity to the extended methods.
Given this, a simple and compelling way to add logic to a
device is to add standard methods that implement ‘rules’. These methods include ‘Assert’, ‘Evaluate’,
etc., and are discussed in detail later.
Since all device extensions conform to these standard interfaces, any
device could, in principle, fire rules in any other device. The determination
of which rules to fire in which devices is not part of the device
implementation, but rather encoded into a common rule data structure.
Many devices have ‘implicit’ rules – a thermostat has a
rule that says ‘when temperature is below the set-point, send message to turn
on the heater’. With embedded computers
inside the thermostat, we can enhance its behavior to also send a message to
the security system (or whatever) – we call this an ‘explicit’ rule.
Adding explicit rules to a device can be implemented in
one of several ways depending on the proximity of the processor to the
device. If the processor is embedded
within the device, rules can be compiled and downloaded into it. If the processor is a controller that
connects to one or more devices, rules can similarly be loaded into the
controller. Finally, if neither an
embedded processor nor a programmed controller is appropriate, the rules can
operate in a general-purpose server computer.
The advantage of a common rule structure across all of
these implementations is (1) they can all compatibly interact with each other,
(2) it is independent of the communication technique and can arguably utilize
any communication facility available (particularly any standard that emerges),
(3) does not require a common operating system nor implementation language to
run in the processors, and (4) encodes the actual functionality of the
interactions so that the design of devices themselves can remain generic.
We present here an overview of the fundamental concepts of
how we model a device and how multiple devices interact through rules.
Device State
Devices are assumed to have a finite state. The total state of a device is the
enumeration of all possible internal configurations or modes that the device
can acquire. The entire system is
therefore subject to the formal modeling techniques of finite-state systems.
Note: An important aspect of the WebEngine is the
adherence to a finite-state model. Here, we concern ourselves with state
transitions as opposed to (say) messages that cause events to happen.
Assertions
The transition from one state to another is the result of
an ‘assertion’. Assertions do not have
direction: an assertion to
a device that ‘causes’ a state transition is indistinguishable from an
assertion from a device indicating the 'effect' of a transition.
Conditions
Closely related to an assertion is a 'condition'. Conditions test
whether a device is in a particular state or not and have a corresponding value
of True or False.
Rules
By combining conditions and assertions, we can construct
simple rules that describe how two or more devices should interact. The rule has three components; a list of
conditions, and two lists of assertions -- a ‘True list’ and a ‘False list’.
Rules have a simple state, either True or False, which is
determined by the AND of all conditions in the condition list. Activity occurs when rules change state. When a rule goes from False to True, the True
list is asserted, and when the rule goes from True to False, the False list is
asserted. This rule construct has been
shown to be simple, convenient, and sufficient with respect to describing most
device interactions.
The logical OR-ing of conditions is accomplished by
multiple rules, since all rules operate in parallel. Practice has shown that this approach is easy
to understand and encourages good design principles thereby minimizing design errors.
Rule processors implemented in embedded devices have the
constraint that the conditions of a rule must all refer to local state. Assertions, on the other hand, can be global
to all scoped devices.
Rule processors implemented in server computers have no
such constraint. In these systems,
interconnected servers create proxy devices for all scoped remote devices. Consistency between these proxy devices and
the remote real devices they represent is automatically maintained, permitting
conditions to appear in rules (actually, it is the conditions of the proxy
devices that are being tested).
An important objective of this system is scalability and
to achieve it we must eliminate the geometric growth in complexity associated
with large numbers of devices. Name
scoping permits the interaction of a practically unlimited number of devices
without the encumbrance of geometric growth in complexity. It does so by permitting the construction of
device-name hierarchies that requires that devices interact on an as-needed
basis, in much the same way that computer languages scope variable names.
Devices interact according to whether they are in-scope or
not. Scope [see section Device
Name-scoping, page 17] determines the propagation of
assertions across multiple interconnected processors. Devices that share a common scope are said to
be 'in-scope' and fully interact according to prevailing rules.
Processing Element Categories
Rule processing is implemented in several different ways
depending on the form of the processing element. To date, several distinct forms have emerged:
·
Networked Computers having general I/O
capabilities
·
Embedded Attached Computers having compiler
runtime capabilities
·
Embedded Micro-processors having interpreted
runtime system
From these definitions, there are three corresponding
types of rule processors:
Figure 1 Rule Compiler, Rule Processor, with Domain
Manager[see below] Architecture
Figure 2 Downloaded Rule Compiler and Rule Processor
Managing Specific Device Types
Figure 3 Server-based Compiler, Rule Processor,
Specific Device
The Savoy WebEngine is organized
into two principle types of components:
·
computing elements that implement device
behavior in the form of a server module,
an attached embedded controller, or an embedded micro-processor within a
device.
·
a set of Client modules for development or viewing.
Multiple Servers can be linked
together, functioning in a peer-peer mode. In general, the Server contains all
of the logic to control devices, including the execution of a rule-based logic
engine.
Client Applications
The Client applications include the
capability for rendering and analyzing device behavior in both spatial and
temporal views. Spatial views are physical layouts of an environment for the
purposes of monitoring and control, while temporal views are a time-line
history of causes and effects required to determine what happened and when. The
Client applications also host application components that install and configure
devices and an editor for creating rules that automate their operation.
For the WebEngine, the advantage of
this network organization is twofold: first, the set of connected Servers can be running continuously,
whereas the Client applications need only run when the user needs to access the
system, and second, the Client applications can access the Server(s) over
networks. Actually, a Client application can connect to multiple Servers, and
at the same time, a Server can be connected to multiple Clients. Savoy
WebEngine Release 2.0 and beyond uses Internet TCP/IP protocols between the
Server(s) and all Clients allowing access over the Internet.
Contrasting Savoy with Others (like Sun's JINI,
Microsoft's Home API, LonWorks, etc.)
Let's say that you want the lights to turn on when you
open the door.
First, if this is all
you want to do, the problem reduces to that of communicating somehow with the
two devices and causing the light to turn on whenever the door opens -- end of
story.
If, however, there are a collection of doors and lights,
and you want different things to happen under different circumstances, and you
want to avoid complex programming, and so on, the problem becomes more complex.
The general problem is referred to as binding -- in this case binding the door to the light switch, and
the question becomes "What do
you bind and when do you bind
it?". In the world of software, of
course, the actual devices become encapsulated by software objects and the
connection between the devices becomes some form of network, and so we cast the
problem into one of binding software objects over a network.
RPCs, RMIs, and ORBs
Historically, this problem has been addressed by Remote
Procedure Call (RPC) facilities in operating systems (Sun's Unix) which
permitted a module on one machine to call a procedure on another. In 1987, Apollo Computer introduced a more
sophisticated RPC using a network based 'broker' to aid in the binding. This technology was transferred to the Open
Software Foundation (OSF) and eventually became the industry standard called
CORBA (Common Object Request Broker Architecture).
With the more recent introduction of the Java language
from Sun, there came along with it a new Virtual Machine (VM) environment and
therefore a need to re-invent an RPC mechanism that they call Remote Method
Invocation (RMI), all wrapped up in a concept called JINI. JINI is advantaged in its ability to move
programs around the network, since all VMs run compatible code. This permits a 'thin client' approach to
binding whereby the called machine 'serves' code that can run as an agent on
the calling machine.
Late Binding
The above are all forms of 'late binding', which attempts
to remove the function from hard core programming and implement it later during system configuration or in
some more flexible programming environment like 'scripting'. But all of these techniques are used within
the world of programming, and when used alone, some programmer has to determine that the light should go on when the
door opens.
This begs the question, "How late can we bind these
objects?". Can we remove the
binding totally from the programming environment? The answer is yes, and there are numerous
ways to do it; one approach is to transfer 'network variables' across the
network, requiring that all devices be properly normalized so the output of one
matches the input of another. LonWorks,
BACNET and others take this approach.
Another way is to have a database that determines what action is
performed as the result of what events. But, who creates the data, how do the
data elements relate to device capabilities?
Further, if you add a new kind of device with entirely different
capabilities, can the data approach accommodate it?
The Savoy
Architecture of Binding
In Savoy,
these data elements are components of rules,
and these rules can be dynamically created, or modified by anyone at anytime --
without disturbing the operation of the system.
To understand how the rule components are formed and used, let's create
a metaphor for the system.
First, we cast all devices into a finite-state model, meaning
that each has a finite number of properties and each property has a finite
number of states (door is 'open' or 'closed').
Now, let's represent each device by (1) a collection of lights, and (2) a collection of buttons. There is a light associated with each state
and when the device is in that state, the corresponding light turns on and all
others turn off. Similarly, there is a
button for each function the device can perform. We assume that all devices can fit this
metaphor.
The function of a rule is to correlate lights and
buttons. Note that our metaphor has
removed any meaning associated with either a light or a button. To the rule engine, all lights and all buttons
look the same. Furthermore, pushing a
device's button does not require a procedural interface at all -- only a simple
message. So, in this model, there is
little point in connecting the device objects together in any programmatic way
-- we need only send messages.
Finally, there is the question of how we wire up the
lights and buttons to form rules; suppose all devices provide little
descriptions of their lights and buttons -- small phrases that help a user
choose among the lights and buttons. A
rule editor uses these descriptions to give a user a simple way to author
rules.
Let's bring our buttons and lights metaphor back to
reality by replacing them with the little description tags mentioned
before. These tags are strings that
carry no meaning outside of the device object that creates them. The rule engine keeps these tags as
components of rules and will send them back to the device for two purposes:
·
to evaluate
whether the device is currently in the state described by the tag, and
·
to assert,
requesting that the device perform a state-transition to the state described by
the tag.
This simplified explanation of the Savoy
architecture explains how it is that new device domains can be added to a
system and immediately placed in rules. It further explains how Savoy
is able to scale from the very simplest device to the most complex. It also suggests that the current emphasis on
procedural interfaces to network based software components is probably over
stated for many applications.
The network server is designed to manage a
large and extensible set of Device types. The set of Device types having common
physical characteristics are grouped into what is called a domain.
Since many Devices represent real-world objects that can be controlled by the
computer, the domain is typically the space of device types that a particular
hardware interface can control.
The Server performs computation at two
distinct levels: (1) within a domain, and (2) across one or more domains.
Computation within a domain is usually limited to dealing with the I/O
peculiarities of the interface and is encapsulated and hidden within a software
component called a Type Manager—so named because it manages the set of
device types defined within the domain. Computation across domains is performed
by an entity called the Rule Processor.
The Rule Processor within the Server
performs Boolean logic across domains in accordance with rules created by
users. This is a simple, but powerful concept. For example, suppose one domain
is the Internet WWW wherein a device type called ‘weather report’ periodically
browses a known Internet site that contains weather forecasts. Suppose a second
domain is an I/O system used to control water valves on a lawn sprinkler
system. Then, with point-and-click simplicity, a user could modulate the
scheduling of the lawn sprinklers in accordance with rain forecasts.
The interface between Type Managers and the
Rule Processor involves what are called assertions. An assertion can
be thought of as either a command to the domain or an event from the domain.
Assertions appear in the Rule Builders used by the user and so they are
typically quite simple and intuitive; they represent the total functionality of
the device type.
Associated with an assertion is a condition.
Conditions also appear in the Rule Builder as a cause phrase, and for many
device types, the condition is identical to the assertion. A condition is a
test of whether the device is in the state or not, and has a value of True or
False. One of the main functions of a Type Manager is to perform these tests
through a method called ‘Evaluate’.
Type Managers typically
·
receive assertions from the Savoy WebEngine and
perform whatever function is required within the domain
·
monitor activity within the domain and translate
this activity into assertions back to the WebEngine when appropriate
·
perform evaluations of conditions and assertions
whenever the Savoy WebEngine wants it to
Normally, a Type Manager will support
multiple devices, usually through a single interface. These devices may be of
different types—for example, a single I/O interface will support multiple
device types (analog input, relay output, etc.) each of which may have many
instances ( 4 Inputs, 3 Relays). Accordingly, the interface between the Server
and a Type Manager includes methods to create and destroy instances of device
types. The create method must return a unique value (an object handle) that is
passed back and forth as a device identifier.
In addition to these, the WebEngine requires
that the Type Managers provide editing dialogs for the user to edit both
assertions and conditions. These are typically simple pop-up windows that
prompt the user and validate the user’s input. Many editing dialogs present
radio buttons so that users don’t have to type anything, making type checking
automatic. These editing dialogs run as separate components loaded by the
WebEngine client application rather than the Server application (permitting the
editing of rules from remote locations), and the WebEngine automatically
handles the serialization and transmission of data between the client and
server portions of a Type Manager.
In practice, then, two software components
are required for each domain – one loaded by the Server and the other loaded by
the WebEngine’s main (client) application. This latter component is referred to
as the Property Manager. Frequently, however, a single Property
Manager can be used for multiple Type Managers if the Type Managers implement
similar device types. For example, many security panels have similar capability
and can all use a common Property Manager. Similarly, while there may be many
interfaces to X-10, each requiring a unique Type Manager, they can all use the
same Property Manager.
Since the editing (and therefore creation)
of both conditions and assertions, as well as the execution of assertions, is
all handled by the Type Manager, the WebEngine itself knows absolutely nothing
about the domain, a concept termed domain independence.
Domain independence will permit the
WebEngine to expand its scope to include many unforeseen domains, simply
accomplished by additional Type Managers. These additional Type Managers can be
incrementally added in the field without any changes to the WebEngine itself,
user layouts, installed devices, or rules. Once a new Type Manager is
installed, new devices can be added, and new/existing rules can use the new
assertions.
Further insight into the role of Assertions
can be gained by comparison to similar concepts in object oriented languages
such as C++.
In C++, calls to an object are termed methods
and calls from the object are termed callbacks. In both cases, data is
passed in the form of explicitly arguments whose types are defined by the
language and checked by the compiler for correctness.
In Type Managers, we have Methods and
Callbacks to the domain interface. To
the domain itself, however, we've modified the approach slightly.
Figure 4: Methods and callbacks to the domain
First, we've named both methods and
callbacks to/from domains assertions.
Second, the data transferred across all
assertions is not passed as individual arguments, but rather as a payload
contained within a single string argument. This approach has two significant
consequences:
1.
A minor disadvantage of having all type checking
performed at runtime and by the object itself rather than the compiler.
2.
A major advantage of freeing the definition of the data
from the C++ compiler in that a single interface can be used for a wide variety
of data types, as is required for domain independence.
The advantage of (2) outweighs the
disadvantage of (1), provided that all Type Managers implement adequate type
checking of their assertions.
Further advantages of this approach become
apparent when considering the task of building rule editors that must combine
conditions and values of multiple domains. Here, the creation and editing of
the data is securely performed by the Type Managers, and yet assembled and
compiled by components in the WebEngine (Editors run on the client and rule
compilers run on the server).
Finally, string data types are already
serialized for communication in a distributed client/server configuration.
Symmetric assertions to/from domains
provides a simple means of performing complex functions across the entire
system. The user can regard the overall operation of the system as an
asynchronous chaining of assertions to/from the rule processor:
Figure 5: Assertions to/from the Rule Processor
It is important to realize the asynchronous
character of this system: at any time, assertions can originate from within a
domain, presumable due to some event occurring through an interface to a
facility. Similarly, at any time, an assertion can originate from the Rule
Processor, presumably due to either a timer event or from a rule triggered by
an assertion from some domain. Rules simply perform Boolean logic on incoming
assertions resulting in output assertions going back to the domains.
A Better Way of Building Procedures
A
procedure is a sequence of operations having a specific order. Conventional
approaches to encoding procedures involves a scripting language, like Basic,
where each operation is specified by a line of code and the system executes
lines of code in sequence. This approach has two major problems: First,
individual operations, especially those involving I/O to devices, can be time
consuming and so to avoid the system from locking up during these operations, a
form of preemptive multi-tasking must underlie the system to permit multiple
script sequences to proceed concurrently. Second, frequently a single procedure
may have sequences that could or should be performed concurrently, and to do
this, the scripting language incorporates a multi-threading mechanism that
permits concurrent threads to be created, synchronized, and so on. These
conventional approaches are both complex and clumsy to use. Some scripting
systems address these issues by a single scanning process that permits user
code to test and set global flags that direct other sequences in the scanning
loop to perform operations; these rudimentary techniques may work for simple
applications, but don’t deserve more than a mention when considering more
complex applications. A better approach is required.
One
better approach is to somehow encode the connections among a set of objects
whereby each object is dynamically receiving messages (methods, assertions),
operating on them, and then sending messages as a response. This, of course, is
precisely what the WebEngine rule processor does, and the connection from the
output of one object to the input of another is called a rule.
Rules
can be designed to chain asynchronous assertions into procedures. Consider an
application where the user wants to take a picture whenever a motion detector
fires and then email the picture somewhere. Since the domains for motion
detectors, cameras, and email all have asynchronous assertions, we can encode
this procedure as a simple chaining of these assertions, as follows:
When
motion | snap picture
When
picture snapped | save to a file
When
file saved | email to someone
When
email sent | …
The
advantage of this approach over procedural scripting becomes apparent in
applications where long periods of time can elapse between assertions. The
asynchronous design of the WebEngine permits a large number of these chained
procedures to run concurrently.
In
the above example, suppose the user wants to impose a 5 second delay after
saving to the file. For this we use a standard Timer,
called Wait:
When
motion | snap picture
When
picture snapped | save to a file
When
file saved | Wait FiveSeconds
Wait
Done | email to someone
When
email sent | …
This
shows that the notion of building procedures out of asynchronous assertions can
be quite compelling. In other operating system environments, the function of
the rule processor would be delegated to task switching, semaphore management,
thread management, co-routining, or some equivalent form of parallel computing.
One additional advantage of our approach is that it naturally spawns parallel
threads: for example, if we wanted to log a message when the file is saved, we
simply add a procedure of the form:
When
file saved | Status The file was saved
The
concept of parallel threads is a fallout of the fact that each individual rule
statement is itself a parallel thread – so much so, that if one stacked up all
of the statements of a all procedures and shuffled them like a deck of cards,
the operation of the system would be unaffected.
In
summary, the reader can regard assertions as asynchronous Methods and Callbacks
to/from the domain object(s) with type independent data as the payload.
The
Savoy WebEngine client is based on components whose APIs are open, published
and royalty-free. As such, they provide
a rich and powerful base to build application specific client programs in
Visual Basic, C++, or Java(soon). These
application clients easily communicate with the WebEngine server(s) and can be
designed to present specific user interfaces or control functions.
Savoy uses the client architecture to implement
extensions to the system, such as a Voice Recognition module.
Savoy
WebEngine as a System
In
summary, the Savoy WebEngine is a computing environment for Devices that
incorporates several new developments:
1.
Device as a persistent object, and class hierarchy of
device types derived from common base class
2.
Device name space which spans networks of servers all
operating in a concert, able to span embedded controllers to network servers,
within a single site or across multiple sites.
3.
Device interaction based on a rule-based computational
element to provide the coordination and control.
The Server component in the Savoy
system is referred to as the WebEngine.
This includes a Boolean Rule Processor designed to synthesize activity
across classes of devices called domains.
The WebEngine normally runs continuously as
a minimized server application on a Windows based computer, or in a more
dedicated machine in a Windows 95/98/NT environment. Its principle function is
to manage the devices local to the facility and execute the Rule Processor to
automate the activity of these devices.
While most environments will likely
run in a single machine, the WebEngine is designed to cooperate with
other WebEngines connected over networks. The WebEngines cooperate in such a
way as to behave as a single entity, allowing for remote facilities to be
managed collectively. Specifically, all WebEngines exchange cause and effect
information allowing causes in one facility to have effects in another (see Rule
Processor section on page 32).
The client/server relationship
between the CyberHs application and WebEngine is supported by the Microsoft
TCP/IP facility for routed and dial-up services, and
Microsoft NetBEUI for LAN connections. Internet operation can be accomplished
as provided that the WebEngine client knows the IP address of the server—easy
if the server is running on a permanent site, more difficult for dial-up
connections where IP addresses are dynamically assigned.
If more than one WebEngine is
connected over a network, they function as peers all sharing a common device
name-space. From a client’s point-of-view, all interconnected WebEngines appear
functionally as a single entity. The organization of the interconnect among
peer level WebEngines is in the form of a parent-child tree as shown below. Servers
can have any number of child servers, but only one parent.
Figure 6: Peer-peer relationship of WebEngines
Each WebEngine is capable of
managing facilities, and the system automatically routes messages up and down,
permitting all WebEngines to see activities from all other WebEngines. Rules in
any single WebEngine can be written for all devices across all WebEngines (see
the Name-scoping section on page 42) without regard to their physical
location, since the device name-space is shared across the system.
Approximately every minute, child
WebEngines ‘ping’ their parent link with a null message to test the integrity
of the connection. If this function fails, the child server goes into a slow
polling mode, requesting service every 30 seconds or so, until the connection
is reestablished. This allows for automatic reconnection in the event that a
WebEngine anywhere in the tree is temporarily removed from service.
Both NetBEUI and TCP/IP are supported in
Savoy WebEngine 2.0, the former recommended for LANs and the latter recommended
for intranet and internet connections. Operation over the Internet requires
that the client application know the IP address of the server, and the only way
to do this currently is through permanent (non dial-up) connections.
A TCP/IP stack is not required for local or
LAN operation; however, a is required.
If TCP is absent, the WebEngine will log a warning and continue with NetBEUI.
TCP/IP is more efficient and for isolated
LANs, users can set up an intranet using IP addresses 192.168.0.N where N is 0
to 255.
A single WebEngine can support multiple
NetBEUI and TCP/IP clients at the same time.
The Savoy WebEngine supports the
Windows 95/98 Remote Access that allows for two or more Windows based computers to be
connected temporarily over dial-up telephone lines. This connection is
permitted under password control guaranteeing authorized access. This
connection can be used for CyberHs application-WebEngine access, Server- Server access
or both. Applications include the ability to access a facility from a remote
portable computer as well as temporarily interconnecting remote facilities.
The execution of the Rule Processor involves translating
causes into effects according to one or more sets of rules.
Causes are the result of some environmental event
including a user clicking on a button (in CyberHs application). Typically, a cause occurs
when a motion detector sends a signal, or when an X-10 device is turned on or off.
The output of the Rule Processor is an effect, typically
resulting in a command sent to an X-10 device, for example. The
logic that determines the effect is described in rules that can range from
extremely simple to quite complex.
Devices, such as wireless motion detectors or X-10 modules are referenced by a
name, specified during the installation of the device. The rule processor does
not distinguish between the various types of devices, and so, at the level of
names, all devices are treated the same.
Figure 7: Naming physical devices
In addition to physical devices sharing a common name
space, Type Managers have been developed for a wide variety of named objects
including state variables that manage ‘scenes’ and ‘events’, Email messages,
Web browsers, and more.
Figure 8: Naming logical objects
All objects can both generate causes as well as receive
effects, which may in turn generate more causes. These devices allow for the
construction of complex objects out of simple ones, which in turn greatly
simplifies the rules that use them.
Most
computer languages, like Basic, FORTRAN and C, are procedural
languages meaning that they encode precise time ordered procedures for the
computer to perform. Other languages are descriptive languages that
encode a description of what to do without regard to how to do it. A subset of
descriptive languages is rule-based languages that encode a set of
logical rules to describe the systems behavior.
In
general, procedural languages, even simple scripting languages, require a
knowledge of the computer implementation, and frequently burden the user with
complex issues of timing, synchronization, keeping track of multiple parallel
processes, and so on. Rule based languages, however, bury all of that
complexity into the language run time system, and provide the user with a far
more elegant framework in which to encode certain types of applications.
The
most popular rule based language is Prolog, which has been used in many
artificial intelligence applications. There are many other rule-based languages
that are integrated into applications, like Mail routing systems for example.
The
Savoy WebEngine uses a rule-based language for encoding the logic for
automation. Unlike Prolog, which is goal oriented, the WebEngine is event
driven, and considerably simpler to learn.
Everyone understands the simple relationship between cause
and effect: namely, causes generate effects. This simple understanding is all
that’s required to create a set of rules that will automate the
operation of the WebEngine. The syntax of the rule language takes the form
cause then
effect;
which is to be interpreted as ‘when the cause occurs perform the effect’.
A rule set is a sequence of these statements; they may
appear in any order, and collectively they form the logic of the system.
An example of a rule set is:
cause1 then
effect1;.
cause2 then
effect2;.
cause3 then
effect3;
. . .
Each of these causes or effects are called a phrase,
typically a device-value pair, such as Lamp
On. We define a phrase list to be a simple enumeration
of phrases, depicted as:
Phrase1
Phrase2
Phrase3
...
A rule is comprised of three phrase Llsts. First is the
list of causes, and the second and third are lists of effects, shown as:
PhraseC1 |
PhraseT1
PhraseC2 |
PhraseT2
PhraseC3
|----------------
PhraseC4 |
PhraseF1
...
The operation of the rule processor is to assert the True
phrase list whenever all cause phrases become true, and the False
phrase list whenever any cause phrase becomes false. In this sense,
cause phrases are AND’d together, while effect phrases are Or’d together.
An effect phrase is either terminated or connected to
another cause phrase of another rule forming a network of rules.
Figure 9: A network of rules
As an example, consider
Figure 10: Example of effects driving causes in other
rules
Each node in the rule network ‘fires’ whenever the AND of
all cause phrases change from false to true, or from true to false. Suppose we
have three phrases, named A,
B, and C, forming the cause
phrase list. Suppose further that the effect phrase lists are phrases X and Y for True and Z for False as shown
below.
Figure 11: Multiple causes and effects
The operation of this rule is shown in Figure 12.
Figure 12: Executing rules with multiple cause
phrases and effects
Most generally, a phrase in a rule can be considered to be
comprised of:
[ObjectName]
| [Function] | [ObjectName Function] Argument(s)
Each component of a phrase is space delimited, so names
used to identify the components cannot contain blanks.
ObjectNames
is typically the name of a device, like LampModule.
More generally, however, it can be a logical device created to hold
state information, perform functions like timers, or abstract a collection of
physical devices into a single logical entity, like AllExteriorLights.
In conventional languages like Basic, these would be known as variables.
Physical devices and named devices coexist in the same name space and are
indistinguishable by the rule processor.
In addition, there are virtual devices that only
exist within the rule sets—no physical or logical device by that name actually
exists. These devices are dynamically replaced when a real or logical device is
created. Conversely, if a real or logical device appears in a rule, and the
device is deleted, a virtual device with that name is dynamically created.
The Function
component of a phrase is typically on,
off, or alarm, clear, etc. They indicate
what the device is instructed to do, or what it has just reported (sensors).
Arguments are used to further qualify a function,
for example LampModule Dim 12,
meaning dim the lamp to level 12. Arguments are used to determine the value of
the expression as in the case of the internal function After
which compares the first argument to the time of day.
MotionDetector
Alarm & After 18:00 | RingChimes & Lamp1 on;
A number of such internal functions exist to enrich the
capabilities of the language.
Since
the scoping of device names in the Savoy WebEngine can extend across peer servers
running in parallel, the above approach works transparently when device objects
are distributed across a network. Assertions to a remote device are
automatically routed to the hosting machine, and assertions from the remote
device are automatically routed back. Consequently, users can write distributed
computing applications without regard to where device objects actually exist.
A partial list of internal functions includes After, At, Beep,
Before, Date, During, Exec, Log, Status,
Invoke, Expire, and Timer. A complete list
together with descriptions of their functions is available in the help
documentation.
From
our previous discussions of rules, we note the multiple views that this single
entity can be presented. In the simplest case, it is a relationship between a
cause and effect:
MotionDetector Alarm | Chimes On;
Or,
it can be a procedure of assertions:
| Chimes On;
Lamp1 On;
Status blah blah;
Relay3 Closed;
Or,
it can be a complex procedure linking asynchronous assertions:
When motion | snap picture
When picture snapped | save to a file
When file saved | Wait FiveSeconds
Wait Done | email to someone
When email sent | RingChimes;
Lamp1 on;
Status blah blah;
Relay3 Closed;
Finally,
groups of these rules can be thought to form a network of rule logic performing
very complex applications.
Rule1
à Rule2
\
à Rule3
…
Of
course, these are all simply different views of the same thing. How any
application is viewed is a personal choice and somewhat dependent on its
complexity.
Passing
Information Across Domains
In
certain circumstances, it becomes necessary for information known within one
domain to be passed to another. For example, an incoming phone call may have a CallerID
value that is desired to be known by another domain, like a TV display.
To
accomplish this in a general way, we attribute each device as having a set of
property values, denoted by DeviceName.Property.
For example, a device belonging to the Phone domain, called IncomingCall,
may have a property called CallerID
(jointly referred to as IncomingCall.CallerID),
whose value at the time a call is received might be Jones_Henry.
This value can be conveyed to any domain by simply stating the device.property
name as an argument to an assertion.
For
example:
IncomingCall Ring | Display
IncomingCall.CallerID;
In
general, Savoy’s Rule Processor translates all string
tokens having the form a.b
(no spaces) into a reference to the property ‘b’
of device ‘a.’
If
device ‘a’ does not exist, the string ‘a.b’
is passed as the value. If device ‘a’
is created, all rule sets that include references to ‘a’
are dynamically recompiled. If device ‘a’
is deleted, all references to ‘a’
are automatically converted back to ‘a.b.’
To
encode an assertion that is comprised of a property, see the example of
assertion templates accessing the properties of the Savoy WebEngine devices
below:
|
|
|
|
|
Any
X-10 device
|
Lamp1.state
|
Dim12
|
|
Temperature
|
Thermostat1.T
|
72
|
|
Set
Point
|
Thermostat1.SP
|
68
|
|
Mode
|
Thermostat1.M
|
H
|
|
All
Security Panels
|
Panel1.state
|
Armed
|
Tunneling
is a technique that connects the output assertions of one domain directly to
the input assertions of another domain, transferring free text arguments
without modification or type checking.
The
WebEngine Rule Processor performs tunneling between device A
and device B by the rule:
A
* | B *;
The
asterisks indicate arbitrary arguments. There cannot be multiple assertions,
and no ‘else’ assertions.
The
Savoy WebEngine rule builders cannot create this rule since the ‘*’s
violate type checking, and so we have created a simple template, called Tunnel,
to create the rule. The template Tunnel
has the form:
^1
* | ^2 *;
where
^1 and ^2
are device names passed in the Use
statement that uses the template.
To
use tunneling, create a rule with no cause assertions, and a single effect
assertion of the form:
Use
Tunnel DeviceA DeviceB;
This
will cause all output assertions from device DeviceA
to be sent to DeviceB.
Example:
Suppose
a Visual Basic application, using the DDE Server Type Manager, wants to
directly control a device, say an X-10 Lamp Module named Lamp1.
Create a device of type
(Menu: ////), called Lamp1Control.
Then create the rule:
Use
Tunnel Lamp1Control Lamp1;
Now,
the Visual Basic application can directly create assertions of the form Lamp1
Dim7 and send it directly to the X-10 domain. Note that this is
performed without type checking and so it is the responsibility of the VB
application to guarantee the integrity of assertions it generates.
As
in any computer application, value is gained through the ease of encoding
higher forms of logic from simpler forms—procedures, structures, and object
classes all lend themselves to this goal.
The
Savoy WebEngine has the capability of using templates to accomplish
this goal. A template is like a procedure, or macro in other languages—it
encodes logic that can subsequently apply to multiple uses. In a template,
names can be derived from arguments passed from a client rule set as in the
example below.
Templates
come in two forms: (1) an entire rule set, and (2) a single assertion.
A
template rule set named Momentary:
Timer ^1Tmr 0 | ^1 Off;
^1 On | Timer ^1Tmr ^2;
This
rather cryptic rule set is designed to create a relay device which is
momentary, meaning that it turns off a few seconds after it is turned on. The
physical device, say Relay, is designed
only to turn on or off, but the application may require that it only
momentarily turn on, lets say for 10 seconds, and then turn off. To do this, we
simply state the rule
Use Momentary Relay 10
This
statement transforms the conventional relay into a momentary relay. The user
need never see the cryptic template rule set—they are contained in libraries.
They can easily be developed by users, however, by simply observing the
relationship between the arguments in the Use
statement with the variables ^1, ^2,
... ^n in the template rule set. Each ^n
is to converted to the nth argument when the rule set is compiled. Typically,
however, the user need only understand the function of the template rule set
and then encode the single statement shown above.
The
momentary rule set can be applied to many types of devices in the same
application.
An
example of a single assertion template is Property
which encodes the property of device B
as an assertion to device A.
The template is defined to be:
^1 ^2.^3;
An
example of its use is:
(Conditions…) | Use Lamp1 Lamp2 state;
Users
must design templates carefully, since their use is not type checked.
A networked application of the system can range from a
CyberHs application running on a laptop computer calling a WebEngine at home computer, to a
complex of linked WebEngines and CyberHs applications at multiple sites. In all
cases, the operation of the system follows a conceptually simple model.
In general, all named devices described above can be
shared across the network of CyberHs applications and WebEngines. For example,
a cause generated from a physical device at one site is sent to all other
sites, allowing any site to generate effects. Consequently, a network of Rule
Processors operate concurrently on all named devices, independent of where they
are. Obviously, care must be taken when designing the rules at remote sites so they
cooperate rather then interfere with each other. A simple example will
illustrate how this works.
Suppose at site A we have a wireless motion detector called Detector, and at site B
we have an X-10 device call Chimes,
and we wish to have rules that allow for the chimes to ring at site B whenever
motion occurs at site A. To implement this, we simply enter the rule Detector | Chimes at either
site A or B—it doesn’t matter which one. Whichever site is chosen, the rule
processor will create a local soft device for the remote physical device. For
example, if we choose site A, then on the left we have:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Named Devices:
Detector, Chimes
|
|
|
|
|
|
|
 |
|
|
|
|
 |
|
|
|
|
|
|
Figure 13: Rules cooperating across facility
boundaries
Consequently, at each site, we can describe rules
for the entire system, regardless of where anything is, providing, of course,
that we do not carelessly conflict with rules at other sites—one site turning
something off while another turns it on, for example.
Arithmetic
Logical Devices
As
of Release 2.5, the Savoy WebEngine has the capability to perform arithmetic
calculations by a new logical device type called Arithmetic Variable Set
(Devices Menu / New Device / Logical Devices/ Numeric Constants & Variables
/ Numeric Arithmetic Variable). This
device computes assertions in the form of an arithmetic expression, similar to
languages like FORTRAN and Basic.
Each
device contains a set of up to 10 variables. Variables are properties of the
device, and can be referenced as ‘Device.Variable’. For example, an Arithmetic device might be
called VariableSet1 and include three variables named X, Y, and Z. A rule for this device could be:
(cause) | VariableSet1 X=
VariableSet1.Y + 3;
Any
other device type which has numeric properties, like a thermostat, can be
included in the arithmetic expression; for example,
(cause) | VariableSet1 Celsius= ( Thermostat1.T - 32 ) * 9 / 5;
where
Thermostat1 is a thermostat having a property T for current temperature. (Note that the property T for thermostats may
be ‘72F’ – non-numeric characters are ignored).
As
in FORTRAN and Basic, items in parenthesis are computed first; parenthesis can
be nested to any level. Operations
include add (+), subtract(-), multiply(*) and divide(/) and are performed left-to-right. All numbers are assumed to be integers.
Random
Numbers
A
special Arithmetic device, called SysVars (Sytem Variable), can be created for
computing generic values such as sunrise, sunset, and random numbers. To do this, create the device (Menu New
Device / Logical Devices/ Numeric Constants and Variables / Std Time Var Set ).
To
reference a random number, use SysVar1.random (will be an integer = 0..99 ).
To
cycle the number generator to the next value, assert “SysVar1 random”.
Example:
(some
condition… ) | SysVar1
random;
VarSet X = SysVar1.random * 3 / 6 …;
Randomizing
Sunset – an Example
Suppose
it is desired to randomize the timing of a light turning on by Sunset +/- 20
minutes. To do this, create two Variable
set devices: one of type SysVar as above, another of type Time, named
TimeSet. Then create a rule:
At 00:01:00 |
SysVar1 random;
|
VarSet X = SysVar1.random * 3 / 6 …;
| TimeSet T1= X.sunset + (
( ( X.random - 50 ) * 60 / 50 )
* 20 );
At TimeSet.T1 | Lights On;
Using
the Numeric Constant Data Type
The
Numeric string device (Devices Menu / New Device / Logical Devices/ Numeric
Constants & Variables / Numeric Constant) permits a user to input numbers 0
through 100 using a slider control. This
device can accept an ‘*’ as a rule condition indicating any change in
value. Its current setting can be
referenced as Number1.state, and so we can combine this device with an
Arithmetic device using the following rule:
Number1 * | VariableSet1 Z=((65+ (
Number1.state / 10 ) ) - 32 ) *5/9;
which
will translate the range of the slider into Celsius over a range of 65 to 75
degrees Fahrenheit. Suppose we want to
have this value adjust a thermostat;
simply add the assertion:
… Thermostat1 SH= VariableSet1.Z;
Activity
in the WebEngine is normally controlled by the operation of a rule engine that
receives assertions from one device and sends assertions to one or more other
devices. Since devices are all cast into
a finite-state model, and since each assertion represents a defined state of a
device, the rule engine can coordinate complex inter-device activity without
any programmatic interface between devices.
Each device can be designed as an independent entity without any
knowledge of any of the other devices.
Occasionally,
assertions require more complex processing than that afforded by simple state
transitions. There may be the
requirement to convert units (say Centigrade to Fahrenheit), or perform
analysis of analog values, and so on. In
principle, many of these requirements could be done within the Domain of the
device, but there may be value in providing users with more flexible control
over the calculations.
To
meet these requirements, Release 4.0 of the WebEngine will include the Java
scripts to augment the operation of the rule engine.
The
concept is that the Savoy rule engine and an embedded Java script
engine sit side-by-side within the server.
Rulesets are typed according to whether they are (a) a set of rules or
(b) a Java script and are thereby directed to the appropriate engine when
loaded.
Users
can create Java scripts in a similar way that rule sets are created. When a new ruleset is created, a user can
simply check the box labeled 'Java script'.
The Graphical Rule Editor automatically adjusts according to the ruleset
loaded permitting the editing of scripts by normal text editing.
Figure 14 Creating a new Java script called AnalogFilter
When this script is loaded into the
Graphical Rule Editor, the editor automatically adjusts to permit text editing.
Figure 15 Graphical Editor in script mode
Java
Script API
In
addition to the standard runtime system provided by the Java script engine, a
number of procedures are available to facilitate communication with the
WebEngine environment. These include:
GetProperty(
strDevicename, strPropertyname, strVariablename );
Retrieves a property of a device
and stores it in a variable.
PutProperty(
strDevicename, strPropertyname, strValue );
Sets a property of a device to a
value.
Assert(
strDevicename, strValue );
Asserts a value to a device.
Bitwise(
operator, arg1, arg2, result );
Parameters
operator
A
string specifying the bitwise boolean operation to perform. Must be one of
“AND”, “XOR”, or “OR”.
arg1,arg2
A
signed, decimal integer. (Note: java
script values are passed as a string)
result
The
name of the variable to which the result will be stored.
Remarks
Performs
the bitwise boolean operation, as specified by
the operator parameter, on the
values arg1 and agr2 and writes the result to the variable specified by result.
Example:
arg1=14;
arg2=5;
result=0;
Bitwise(“AND”,arg1,arg2,”result”);
//result
now has the value: 4
Server
commands
The
Assert(strDevicename,strValue) procedure includes
assertions to the Server which will perform server functions including:
Assert(
"Server", "Status " + strMessage );
