WO1998050830A1 - Method and system for control systems authoring - Google Patents

Abstract

The present invention includes a system for configuring component installation and operation of residential and commercial control and automation systems. In particular, the present invention includes a tiered configurable system for installing and modifying control systems for such features as lighting control, heating, ventilation, air conditioning, security functions, entertainment, and other user interfaces. The system utilizes menus and objects to allow association of connected devices and functions. The system also includes tiered privileges for system operators.

Description

METHOD AND SYSTEM FOR CONTROL SYSTEMS AUTHORING

FIELD OF THE INVENTION

The present invention relates to a method and system for providing configurable installation and operation of residential and commercial control and automation systems, and more particularly to a tiered configurable system for installing and modifying control systems for such features as lighting control, heating, ventilation, air conditioning, security functions, entertainment, and other user interfaces, utilizing menus and objects to allow association of connected devices and functions.

BACKGROUND

In recent years, both the number and variety of electronic devices and appliances in use have increased dramatically. Lighting systems, personal computers (PCs), video tape recorders, compact disc (CD) players, stereo receivers, and televisions are but a few of the most common devices found in both residential and commercial settings. Even appliances that rely on non-electric power sources, such as gas burning furnaces, are usually controlled electronically.

Reflecting the variety of devices now available, many different systems and devices are used to provide more centralized or automated control of the appliances found in the home and the office. These can be as simple as a remote-control entertainment system comprising a CD player, stereo and television, or as complex as a building environmental control system for regulating HVAC and security functions. Some automation systems attempt to address these limitations through the use of menu driven interfaces, which are connected to a single, dedicated control processor. With such a system, a user may control various systems, such as lighting, HVAC, and security, from a single type of interface that uses a common methodology for interacting with the user. In general, such interfaces incorporate a display, typically a cathode ray tube (CRT) or liquid crystal display (LCD), which provides the user with several options for controlling one or more systems in the setting. In a typical control system in the existing art, there is a trade off between flexibility and ease of use. More flexible systems are difficult to use and require a higher level of expertise by the user. If the system is relatively easy to install, little expertise on the part of the installers in the field is required. For example, these installers typically do not need to be computer programmers to make these systems work. However, in order for these systems to be simply installed by installers with minimal computer and other expertise, systems of the existing art typically become more and more simplistic in the nature of what they capable of doing. These flexibility limitations further limit the service provider in providing types of services. This can especially be a problem when the service provider is attempting to service a broad base of customers and services.

An example of problems with existing art is as follows. A security system service provider has an account with a retail automotive service chain, providing, among other things, security monitoring. This monitoring is provided through a central control unit. The retail automotive service chain requests that the security system service monitor the level of grease in a waste grease pit to schedule for pick up when necessary and to call a removal service through the security system. A problem arises, however, because in order to add this function to the existing monitoring and control system, the security system service provider could have to wait as long as 12- 18 months for a change in the software to be made by an outsource software provider.

SUMMARY OF THE INVENTION

It is an object of the present invention to overcome the limitations of existing art by providing a configurable method and system for installing, operating, and modifying control systems.

It is a further object of the present invention to provide a simple graphical user interface (GUI) for installation and association of controls and connected devices for control systems.

It is a further object of the present invention to provide terminal based method and system for configuring control systems. It is a further object of the present invention to provide a menu-based method and system for configuring control system components.

It is a further object of the present invention to provide tiered levels of system installation components. It is a further object of the present invention to provide tiered levels of system access privileges.

It is a further object of the present invention to provide a method and system for modifying the menus of a site-specific control system.

It is a further object of the present invention to provide a method and system for modifying system menus for a type of control system.

The present invention provides a simple graphical user interface (GUI) for a control system installer, such that the installer is able to point and click on functions to install and configure the functions. The GUI also provides the service provider with the ability to fully customize the system. An embodiment of the present invention includes a modular design method and system, in which modules or profiles are created by a system operator at one level of training but are usable by installers at much lower training levels.

To achieve the stated and other objects of the present invention, as embodied and described below, the invention includes a method for a user to configure a programmable control system, comprising the steps of coupling a terminal having a control system database to the programmable control system, wherein the programmable control system is programmable by a control system program and is coupled to devices and interfaces; inputting to the terminal a list of devices and interfaces connected to the programmable control system; automatically presenting the user with a plurality of functions to associate with the connected devices and the connected interfaces; the user selecting functions to associate with each of the devices and interfaces in the inputted list of connected devices and interfaces; automatically compiling a control system program, wherein the control system program associates the selected functions with each of the devices and interfaces in the inputted list of connected devices and interfaces; and automatically downloading the compiled control system program from the terminal to the programmable control system, such that the programmable control system is programmed.

Additional objects, advantages and novel features of the invention will be set forth in part in the description that follows, and in part will become more apparent to those skilled in the art upon examination of the following; these features may also be learned by practice of the invention.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 presents an overview of the system elements of an embodiment of the present invention.

FIG. 2 contains a diagram of the users levels and overlapping elements for an embodiment of the present invention.

FIG. 3 is a conceptual diagram linking a device, graphical user interface (GUI) screen, object diagram, and software code information for an embodiment of the present invention.

FIG. 4 is a table of hardware information for an embodiment of the present invention.

FIG. 5 is a flow diagram of the steps for the method of an embodiment of the present invention. FIG. 6 shows an introductory window of a GUI for an embodiment of the present invention.

FIG. 7 presents a customer information screen containing existing information for a GUI of an embodiment of the present invention.

FIG. 8 is the display page for customer loading of information for a GUI of an embodiment of the present invention.

FIG. 9 contains a new customer information input screen for a GUI of an embodiment of the present invention.

FIG. 10 shows a system hardware definition screen for selecting the Control2 device for a GUI of an embodiment of the present invention. FIG. 1 1 presents the Control2 wizard screen for a GUI of an embodiment of the present invention. FIG. 12 is a window for Control2 interface details for a GUI of an embodiment of the present invention.

FIG. 13 contains a system hardware definition screen for selecting the audio matrix device for a GUI of an embodiment of the present invention. FIG. 14 presents the audio matrix wizard screen for a GUI of an embodiment of the present invention.

FIG. 14A contains the popup window for an option to add all keypads for a GUI of an embodiment of the present invention.

FIG. 15 is a window for audio matrix details for a GUI of an embodiment of the present invention.

FIG. 16 contains a system hardware definition screen for selecting the MagicPad™ device for a GUI of an embodiment of the present invention.

FIG. 17 presents the MagicPad™ wizard screen for a GUI of an embodiment of the present invention. FIG. 18 is a window for MagicPad™ details for a GUI of an embodiment of the present invention.

FIG. 19 contains a system hardware definition screen for selecting the audio keypad device for a GUI of an embodiment of the present invention.

FIG. 20 presents the audio keypad wizard screen for a GUI of an embodiment of the present invention.

FIG. 21 is a window for audio keypad details for a GUI of an embodiment of the present invention.

FIG. 22 contains a system hardware definition screen for selecting a thermostat for a GUI of an embodiment of the present invention. FIG. 23 presents the thermostat wizard screen for a GUI of an embodiment of the present invention.

FIG. 24 contains a system hardware definition screen for selecting a second thermostat containing HVAC interface details for a GUI of an embodiment of the present invention. FIG. 25 is a window for default thermostat settings for a GUI of an embodiment of the present invention. FIG. 26 presents the system hardware definition screen for selecting all devices for a GUI of an embodiment of the present invention.

FIG. 27 contains the compile form screen for a GUI of an embodiment of the present invention. FIG. 28 is a window for delay during compiling for a GUI of an embodiment of the present invention.

FIG. 29 presents the upload screen for compiled information for a GUI of an embodiment of the present invention.

FIG. 30 shows the popup window that appears during upload of compiled information for a GUI of an embodiment of the present invention.

FIG. 31 contains an example sketch of hardware and objects to assist designer functions for an embodiment of the present invention.

FIG. 32 is a window containing buttons for a MagicPad™ for a GUI of an embodiment of the present invention. FIG. 33 presents a window of the designer pages tab for a GUI of an embodiment of the present invention.

FIG. 34 shows the window for the select a button form for a GUI of an embodiment of the present invention.

FIG. 35 contains the button screen for the MagicPad™ for a GUI of an embodiment of the present invention.

FIG. 36 is a window for creating a button for a GUI of an embodiment of the present invention.

FIG. 37 presents the add button information screen for a GUI of an embodiment of the present invention. FIG. 38 contains a table of variables information for a GUI of an embodiment of the present invention.

FIG. 39 is a table summary of commands for a GUI of an embodiment of the present invention.

FIG. 40 presents a menu flowchart for a GUI of an embodiment of the present invention. FIG. 41 shows the menu flowchart of FIG. 41 with star highlights of a logical button placed on three pages for a GUI of an embodiment of the present invention.

FIG. 42 contains a flow diagram of hardware environment definitions using object diagrams for a GUI of an embodiment of the present invention. FIG. 43 is a customer window for a GUI of another embodiment of the present invention.

FIG. 44 presents the object diagram for a node for a GUI of another embodiment of the present invention.

FIG. 45 shows the network hardware nodes initialization screen for a GUI of another embodiment of the present invention.

FIG. 46 contains the audio sources screen for a GUI of another embodiment of the present invention.

FIG. 47 is a window for the audio zones for a GUI of another embodiment of the present invention. FIG. 48 presents the security screen for a GUI of another embodiment of the present invention.

FIG. 49 shows the HVAC window for a GUI of another embodiment of the present invention.

FIG. 50 contains the XI 0 screen for a GUI of another embodiment of the present invention.

FIG. 51 is a window for modem node for a GUI of another embodiment of the present invention.

FIG. 52 presents the designer page screen for a GUI of another embodiment of the present invention. FIG. 53 shows the button object window for a GUI of another embodiment of the present invention.

FIG. 53 A contains the object diagram for button for a GUI of another embodiment of the present invention.

FIG. 54 is a window for the routine object for a GUI of another embodiment of the present invention. FIG. 54A presents the object diagram for routine for a GUI of another embodiment of the present invention.

FIG. 55 shows the functions window for a GUI of another embodiment of the present invention. FIG. 55 A contains the object diagram for functions for a GUI of another embodiment of the present invention.

FIG. 56 is a window for an edit routine for a GUI of another embodiment of the present invention.

FIG. 57 shows the variables window for a GUI of another embodiment of the present invention.

FIG. 57 A presents the object diagram for variables for a GUI of another embodiment of the present invention.

DETAILED DESCRIPTION The present invention relates to a method and system for providing configurable operation of residential and commercial control and automation systems. In particular, the present invention includes a tiered configurable system for installing and modifying control systems for such features as lighting control, heating, ventilation, air conditioning, security functions, entertainment, and other user interfaces. The present invention also particularly relates to a method and system that includes tiered privileges for installers, designers, and profilers of control systems.

An embodiment of the present invention comprises a program, such as a database program, that runs on a personal computer running an operating system, such as Windows 95 or Windows NT. An embodiment of the present invention is referred to as a control system Authoring Tool. The control system Authoring Tool embodiment of the present invention is used to configure (e.g., program) the operation of a control system, such as the Control2 system, which provides residential and commercial control/automation functions for a variety of purposes. The Control2 system was filed as Application Serial No. 08/749,341, filed November 21, 1996, and is hereby incorporated by reference. Uses of the control system, such as the Control2 unit, include lighting control, heating, ventilation, air conditioning, security functions, entertainment, and various associated user interfaces.

In an embodiment of the present invention, the Authoring Tool is used by a control system installer to configure the control system for installation in a particular application. FIG. 1 presents an overview of the system elements for an embodiment of the present invention. As shown in FIG. 1, a user 1 at a computer 2, such as a PC, connects 3 the PC to a control unit 4, such as a Control2. The control unit 4, is connected 4a to various items to be controlled, such as lights 5, HVAC 6, and industrial processes 7. In an embodiment of the present invention, the control system Authoring Tool provides three sections containing tiered levels of privileges, which are referred to as the installer section, designer section, and profiler section. Through forms presented using a graphical user interface (GUI) in, for example, a typical Windows™ fashion, each section allows a tiered level of access to and control of a series of related database tables. FIG. 2 presents a conceptual overview of an embodiment of the present invention. In an embodiment of the present invention, the sections further include three tiers of security levels corresponding to the three levels of system operators.

As shown in FIG. 2, the three levels of system operators include the profiler 10, the installer 12, and the designer 1 1. The profiler 10 possesses the most access and control of the databases and uses all of the skills required of designers 11 and installers 12. Outputs from the profiler's activities — "profiles" — make the installer's job easier by providing an inventory of canned solutions for installation. The designer has access to all of the forms needed to create and modify the discrete logical objects that the profiler builds into profiles. When a solution is required that is not already available to the installer, the designer creates the logical solution, which is savable for the particular customer, or the solution can be profiled for use in other customer databases requiring the same solution.

An embodiment of the present invention also includes three sections, which correspond to skill levels and access privileges for the three system operator levels. These sections are referred to as: 1) profiler section; 2) installer section; and 3) designer section. In an embodiment of the present invention, once a service provider has identified and profiled all of its solutions for its customers, the installer is the only section necessary for work in the field.

In an embodiment of the present invention, in order to properly perform required functions, the installer utilizes only basic computer skills involved in the typical user interfaces presented with Windows™ programs. Entering a particular customer's information and configuring the system of an embodiment of the present invention requires the filling in of blanks and selection of items from various dropdown lists on the forms presented to the installer. Compiling the customer's database and downloading to the control device, such as the Control2, are simple one step actions. Further information about and examples relating to the tasks performed by the installer are described below.

The designer requires skills that allow thorough understanding and ability to perform all of the installer functions of the present invention. Prior programming experience is not necessary. The forms presented to the designer allow the creation and modification of objects in a relational database. A particular customer's database contains many objects. These can be visualized as a database representation of any of the actual hardware objects, such as a Control2, MagicPad™, or Keypad, that the installer enters as part of creating a system for a customer. Other logical objects are also in the customer's database and can be conceptualized as the many pages and buttons that can be displayed on a control device, such as a MagicPad™, or assigned to a keypad.

The conceptualization of these objects is important to optimum utilization of the present invention. To assist in the understanding of objects, a convention called an "object diagram" is herein described and used throughout (see FIG. 3 for an example object diagram). The object diagram is a method of representing the various objects that the forms present to the designer and the relationship of the various objects to one another. The object diagram is not part of the present invention and is only discussed as a descriptive tool to aid an individual in understanding the designer skills. The profiler requires an understanding of all of the installer and designer portions of the present invention. A "Profile" is the result of the profiler defining the user interface for a hardware object connected to the system of the present invention. For example, if the system operator wishes a particular hardware object, such as a MagicPad™, to provide status display and control of an HVAC zone in exactly the same fashion for potentially hundreds of customers, a profile may be created. Without the "profile," the installer would have to take several steps to install a basic MagicPad™ and ensure that all the pages and buttons were available in each of the customer's databases. With the profiled MagicPad™, the installer simply selects the MagicPad™ with the desired "profile" from a list, and the task is complete. Further detail with regard to functions performed by the profiler are discussed below.

In an embodiment of the present invention, the installer configures a system for final installation. Once the installer enters the physical layout of the system into the operating system, an embodiment of which is referred to as the Authoring Tool, the system tells the installer how to set up the addresses for the network nodes

(hardware devices). Existing customer databases are installed, as necessary, or new customer databases are created. Typically, several "profiles" are available to the installer, allowing the tailoring of the various system interface devices to meet the needs of common customer installation requirements. In an embodiment of the present invention, the installer selects devices to install into various locations at residential or commercial property. These devices include key pads, Control2 processors, thermostats, and audio control systems. In an embodiment of the present invention, these devices are installed by selecting them from a list. In an embodiment of the present invention, the installer uses a constrained list for installing, and the only typing performed by the installer is for labeling. Once an element of the system is in place and named, all interaction with that device or other element is performed by the operator pointing to and clicking on an item, using, for example, a mouse. This approach has the additional benefit of preventing typographical errors, which could create system problems. In an embodiment of the present invention, after making all of the appropriate installation selections, the installer chooses an option to compile the selections. The system then automatically compiles and downloads selections to the control unit, thus programming its functions.

In an embodiment of the present invention, the designer has the capability to customize any aspect of a database. The designer uses both installer and designer tools to create discrete logical objects for use in providing a solution to virtually any installation requirement. A configuration modified by the designer is savable as an individual customer's data or may be used as a default system configuration. Default configurations are useful if the service provider has one or more standard offerings that are implemented across many customers. Thus, in an embodiment of the present invention, in contrast to the installer, who may perform only limited physical object functions, the designer has control of physical and logical objects. In addition, the installer can give installed items new names/labels. For example, the installer can provide the thermostat in the master bedroom with an on-screen label within the system indicating that the particular thermostat selected controls the master bedroom.

In an embodiment of the present invention, the designer, with the correct password, is able to remove functions from the operating tool and has the capability of completely overriding any of the functions that the system is programmed to perform. For example, a system may be installed in a particular business with menus for the system appearing on the system keypads in English. If somebody new started working in the company who speaks German, the designer could address this issue: the designer has the ability to create additional menus and additional functions, such as button labels in German; further, the designer is able to provide a set of buttons that provide an option for selecting which language the system displays. These changes that the designer makes are designed to affect one particular customer, the customer whose data are being manipulating at that time.

In an embodiment of the present invention, the profiler defines the user interface for a device to be connected to the system. The data defined by the profiler is applied when an installer adds the profiled device. Profiling allows each service provider to create their own unique solutions for their marketplace. Once this process is done for each potential attached device, the installers automatically duplicate this solution by selecting the desired profile from a dropdown list on the installer's hardware form.

In effect, for an embodiment of the present invention, the task of the profiler is very similar to the designer, the difference being that the profiler creates what are referred to as "profiles." Profiles are used by the installer when the installer adds new hardware. An example of this is as follows. At the installer level, when the installer selects an option to "add a thermostat," a menu pops up asking the installer which profile to apply to that thermostat. In an embodiment of the present invention, the system includes a list of appropriate profiles. A list of these profiles could, for example, include English language — residential; bilingual English and German — residential; commercial; passcode lockouts; and various other sets of functions and menus appropriate for use with the thermostat in different types of installation. The installer selects which profile to use and data relating to the profile that was created by the company's profiler is imported. Returning to the previous example of the designer who creates the German language menu, if the customer happens to be in an area where there is a lot of German language speaking people, rather than have the designer perform the addition of the German language option for each one of the installations, the company's profiler can create a new menu system for the thermostats that have both English and German. After the creation of this new menu system, the next time the installer in the field runs across that situation, the installer simply selects that profile to load and no custom programming for the job is required. The present invention thus allows the installer to use modules that were created by a profiler, without the installer having any knowledge of how the modules work or any other knowledge than how and when to select them; selection is simply based on the name and description of the profiles provided to the installer and whether the selected module fits the particular application being installed.

In an embodiment of the present invention, the designer has sufficient privileges to change any aspect of the system. The designer can modify any button, change what any button does, what information is displayed, or how the button operates for one particular customer, among other things. The profiler has sufficient privileges to change what the defaults are that the installer uses. Thus, in an embodiment of the present invention, the profiler's changes are more profound in that they can affect all the company's customers as opposed to just the customer for which the designer is currently customizing the system. Thus, in an embodiment of the present invention, the system creates data that is later downloaded to a control device, such as the Control2 processor, for the purpose of executing that data, executing that program, and controlling temperature, heating, ventilation, air conditioning, entertainment, or whatever other systems are being controlled by the particular installation. An embodiment of the present invention includes a GUI for function and operation. In an embodiment of the present invention, this GUI is a Windows™-based program, which allows the user to proceed to either an icon or menu to select the program and to run it. When the GUI of the present invention is first accessed, the system automatically queries the user to direct the system to where data to be downloaded is located. This sets as a default for the system the location of data, such as on the user's local hard disk or on a network. After that, the user is prompted to load a particular customer to work on, or to add or delete customers, as selected.

The GUI for an embodiment of the present invention using an example installation by an installer will now be described. Once the user has selected a customer, the installer proceeds through a list of hardware and selects hardware to add (e.g., hardware the user is preparing to install or hardware that the user has just installed at this location) and selects the appropriate profiles as the system prompts for which profile to apply. At that point, the installer renames the generic names that are applied. For example, the installer may provide names to thermostats in rooms so that the menus read "living room, dining room, master bedroom," as opposed to "zone 1, zone 2, zone 3." The installer then selects a button called "compile" to compile the information.

Compiling translates the data into a format that is acceptable for the device, such as the Control2, as opposed to a format that's acceptable for a human readable interface like the Authoring Tool. Once that compiling is complete, the Authoring Tool downloads the data to the device, such as the Control2, through the computer serial port (RS232 port). Once the downloading is complete, the installer disconnects the Authoring Tool from the device, and the device is enabled to run autonomously based on the commands downloaded from the Authoring Tool.

In an embodiment of the present invention, an installer has three main sections from which to make selections: customer, hardware, and compile. Once the installer has finished these three sections, the installation is essentially complete. The designer is called in if there is something unique in that particular installation.

A complete example of an installation requiring services of an installer, designer, and profiler for an embodiment of the present invention will now be described. In this example, the device being installed is going into a fast food restaurant, and the manager during the installation asks the installer to address a problem with a grease pit overflowing so that the manager is reminded to check the pit and assure that service is scheduled to pump out the pit. As part of the reminder, the manager requests that the installer add a liquid level sensor, have the system sense when the pit fills, and automatically call for service and alert the manager that service is needed.

In response to the manager's request, a designer comes to the restaurant and programs the additional function. The designer adds customized buttons to an installed interface, such as the MagicPad™ user interface; these buttons indicate the level of grease in the pit. The designer also adds an alarm on the MagicPad™ user interface to indicate when the pit is full. In addition, the designer may program the system to dial out to a monitoring station or to a pager number so that the proper parties are alerted that they need to call for service at the particular installation. In this example, because this last function is a unique function to this particular store, it is unnecessary for a profiler to be involved; the function is programmed as a one of a kind to this particular installation.

If, however, it turns out that this fast food restaurant is part of a chain of restaurants, and they all suffer from the same problem, then a profiler could create a profile specific for that type of restaurant. If such a profile is created, when the installer adds the hardware, the profile is set to automatically query the installer whether to apply the profile. If the installer selects the profile, the job is done, and no additional programming is required; further, neither the designer nor the profiler need to get involved.

In an embodiment of the present invention, the profile is added to an installed controller using a computer, such as a PC. In an embodiment of the present invention, the same computerized Authoring Tool is used for the installer, the designer, and the profiler. Privilege differences among the three are accomplished through use of password protected functions specific to the designer and profiler. In an embodiment of the present invention, no security requirement applies for the installer.

References will now be made to embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

In an embodiment of the present invention, an installation scenario is used to introduce the tasks required of the installer. The scenario that will now be presented is purposely simple in order to present a brief but complete example installation using the primary forms presented to the installer. The actual sequence of tasks and forms used varies depending on the complexity of an installation, but this scenario is sufficient to describe the necessary steps for an installer to complete an installation and provides references to other less frequently used tasks.

The scenario assumes that the installer has the Authoring Tool installed on a computer and that this is a new customer installation. An installer will typically use a laptop computer to meet the requirement of going to customer locations. However, it should be noted that if an installation's requirements can be met with an existing customer database stored in the Authoring Tool, then the control device, such as the Control2, can be programmed off site and sent to the customer's location for physical installation. The installer could therefore complete all the tasks from a desktop PC. In the scenario, the installer is given information on the new installation. This may be a simple verbal request but in most cases it is some form of hardcopy installation specification, such as a set of blueprints, installation specification sheet, or proposal. In order to proceed, the installer needs some basic information such as: 1) the type and number of hardware nodes (devices); 2) the type and number of any other equipment; 3) the type of audio source equipment owned or to be used by the customer; 4) the number of audio and HVAC zones; and 5) the locations for each of the above.

For this example, the table shown in FIG. 4 provides all the information required by the installer. In this example, the installer travels to the site and performs the installation.

There is no other customer database stored on the installer's laptop that will meet these requirements, so the installer must select the option to 'Add' a new customer.

Only basic hardware nodes are used in this example. Profiles defining preexisting interfaces for the hardware devices are discussed later. The following is a sequenced list of the tasks that the installer performs to complete this example installation: 1) run the Authoring Tool; 2) select a data storage directory; 3) add a new customer; 4) enter hardware nodes (devices); 5) compile the newly created customer program; and 6) update the Control2 (upload from the laptop to the Control2). Each task is presented as follows with step-by-step instructions. Some variance in the sequence of steps is possible; however, this sequence is used to keep the flow of the example going. Where alternative tasks are possible, a reference is made to a later explanation of options.

A flow diagram for the GUI of an embodiment of the present invention is presented in FIG. 5. As shown in FIG. 5, in step SI, the user selects a directory. In step S2, the user creates/loads customer data, which includes options for add a customer S2a, delete a customer S2b, get a customer S2c, import S2d, backup S2e, export S2f, and print manual S2g.

The flow diagram, as an example, further details the process for add customer S2a and get customer S2c. If the user selects add customer S2a, in step S3, the user inputs data. In step S4, the user defines the system hardware. If the user selects get customer S2c, the system proceeds directly to step S4, wherein the user defines the system hardware.

In step S5, the user selects the device, which includes options for all S5a, Control2 S5b, MagicPad S5c, thermostat S5d, HVAC interface S5e, modem S5f, J-

Book S5g, audio keypad S5h, audio matrix S5j, net monitor S5k, and pulse counter S5m. In step S6, it is determined whether all devices are profiled. If no in step S6, the system proceeds to step S7. In step S7, the system provides an option to select profiles.

If the option to select profiles is selected in step S7, the system proceeds to step S8. In step S8, the user selects a profile for a device. In step S9, a network address is automatically assigned to the device. In step S10, the system proceeds to the next selected device, which returns the system to step S5.

In step S7, if the user does not select profiles, the system proceeds to step SI 1. In step SI 1, the user inputs details for the device. In step SI 2, a determination is made as to whether the device is a Control2. In step SI 2, if the device is not a Control2, the system returns to step S8. If the device is a Control2, the system proceeds to step SI 3, in which the system performs a reboot return, or the system proceeds to step S14 for X10 inputs and outputs. After step SI 4, the system returns to step S8. In step S6, if all devices are profiled, the system proceeds to step S15 to query the user as to whether to compile. If the user selects not to compile, the system exits. If the user chooses to compile, the system proceeds to step S16 to compile, which includes sending data to the control unit SI 6a, updating the control unit SI 6b, compiling data SI 6c, and editing ValueLists S16d. GUIs for the installer for an embodiment of the present invention will now be described. These GUIs are presented in FIGs. 6-30.

FIG. 6 presents the first window 30 presented to the installer, which is the select data storage directory form. The data storage directory defines where the customer data is stored. The window 30 includes a data entry area 31 for inputting a directory. If the data entry area 31 is left blank, the system automatically selects the default directory. If a directory other than the default is desired, the installer clicks the browse button 32 and navigates to the desired directory, or the installer simply clears the data entry area 31 and types in the path of the desired directory. Once the installer has made data storage directory selections, the installer selects the continue button 33 to continue or the exit button 34 to exit the system. FIG. 7 shows the window 40 for the customer form, having a tab 40a. The customer form window 40 automatically opens with customer information from the last time the Authoring Tool was used. If there were no previous customers in the database, NEW is displayed. The window 40 includes buttons for add 41, get 42, import 43, delete 44, backup 45, export 46, and print manual 47. The window 40 also includes input areas for customer information 48 and notes 49. Customer information 48 includes last name, first name, number, street, city, state, zip code, phone, install date, and installer. In addition, the window 40 includes tabs to additional screens for hardware 49, compile 50, profiles 51, and designer 52. An example of input information windows and procedure for adding a customer will now be presented. In FIG. 7, to add a customer, the installer selects the add button 41. As shown in FIG. 8, a customer loading screen 55 appears. This page is displayed for approximately 15 seconds while the necessary database structures are created for the new customer. FIG. 9 contains the window 40 for adding new customer data. The installer enters the applicable customer information in the spaces provided in the customer data section 48. The customer number is entered automatically be the Authoring Tool. The installer may also enter any notes desired for the customer in the notes section 49. Once the customer information is entered, the installer selects the hardware tab 49. In FIG. 9, after the installer selects the hardware tab 49, a window 60 appears, as shown in FIG. 10. In an embodiment of the present invention, this window 60 contains the IntelliNet Hardware Devices (Nodes) form, which allows the installer to enter the individual hardware devices for a customer. The window 60 for this customer includes toggle buttons for Control2 61, MagicPad™ 62, thermostat 63, HVAC interface 64, modem 65, J-Book 66, audio keypad 67, audio matrix 68,

NetMonitor 69, PulseCounter 70, and all 71. The window 60 also includes buttons for report 72, add 73, and delete 74, a sort selection dropdown list 75, and an information area 76. In this example, the installer selects the Control2 toggle button 61 , and then the add button 73 to add a Control2. The system then presents a window 80, as shown in FIG. 11. In an embodiment of the present invention, this window 80 contains the IntelliNet Wizard Form, which includes a dropdown list 81 for selection of the Control2 and any profiles desired. All of the tasks in this example installation are basic, without profiles. The window 80 also includes buttons for continue without profiles 82 and continue using profiles 83, and an area for profiler's notes 84. In this example, the installer selects C2 (Basic) from the dropdown list 81 and selects the button for continue without profiles 82.

The window 90 shown in FIG. 12 now appears. The window 90 for this customer and the added Control 2 includes toggle buttons for Control2 91, MagicPad™ 92, thermostat 93, HVAC interface 94, modem 95, J-Book 96, audio keypad 97, audio matrix 98, NetMonitor 99, PulseCounter 100, and all 101. The window 60 also includes buttons for report 102, add 103, and delete 104, a box indicating the name of the hardware selected 105, a sort selection dropdown list 106, an information area 107, and a notes area 108. In this example, C2 is the default name for the Control2, as shown in the box 105. If desired, the installer enters a different name (e.g., the Control's physical location). A network ID (address) is automatically assigned by the Authoring Tool, as shown in the information box 107. (In an embodiment of the present invention, the Control2 is always address 0.) The notes section box 108 is available for use by the installer for text entry of any information that may be helpful. FIG. 13 presents the window 60 of FIG. 10 for installation of the audio matrix.

To add the audio matrix, the installer selects the toggle button for audio matrix 68 and then selects the add button 73.

As shown in FIG. 14, in an embodiment of the present invention, the IntelliNet Wizard Form window 110 appears and dropdown lists are presented for selecting the number of audio matrixes 111 and profiles for the audio matrixes 112. The window 110 also includes buttons for continue without profiles 113 and continue using profiles 114, and a profiler's notes area 115. In this example, the installer selects AM (Basic) from the profile for audio matrix dropdown list 112, and then selects the continue without profiles button 113. A pop-up window 120 then appears, as shown in FIG. 14A. This pop-up window 120 provides the installer with the option of adding all six audio keypads now (with one active button 121 action), or the installer can decline to add all of the keypads now using the decline button 122.

As shown in FIG. 15, a window 125 now appears. The window 125 for this customer and the added audio matrix includes toggle buttons for Control2 126, MagicPad™ 127, thermostat 128, HVAC interface 129, modem 130, J-Book 131, audio keypad 132, audio matrix 133, NetMonitor 134, PulseCounter 135, and all 136. The window 125 also includes buttons for report 137, add 138, and delete 139, a box indicating the name of the hardware selected 140, a sort selection dropdown list 141, an information area 142, and an audio matrix details area 143. The audio matrix details area 143 includes input areas 143 a that include dropdown lists for selecting equipment, buttons for reboot 143b, sources 143c, zones 143d, 1st zone on 143e, and last off 143f, and a notes area 143g. In this example, MATRIX_1 is the default name for the audio matrix, as shown in the box 140. If desired, the installer enters a different name (e.g., the audio matrix's physical location). A network ID (address) is automatically assigned by the Authoring Tool, as shown in the information box 142. FIG. 16 presents the window 60 of FIG. 10 for installation of the MagicPad™. To add the MagicPad™, the installer selects the toggle button for MagicPad™ 68 and then selects the add button 73.

As shown in FIG. 17, in an embodiment of the present invention, the IntelliNet Wizard Form window 150 appears and dropdown lists are presented for selecting the number of MagicPads™ 151 and profiles for the MagicPads™ 152. The window 150 also includes buttons for continue without profiles 153 and continue using profiles 154, and a profiler's notes area 155. In this example, the installer selects MP (Basic) from the profile for MagicPad™ dropdown list 152, and then selects the continue without profiles button 153.

As shown in FIG. 18, a window 165 now appears. The window 165 for this customer and the added MagicPad™ includes toggle buttons for Control2 166, MagicPad™ 167, thermostat 168, HVAC interface 169, modem 170, J-Book 171, audio keypad 172, audio matrix 173, NetMonitor 174, PulseCounter 175, and all 176. The window 165 also includes buttons for report 177, add 178, and delete 179, a box indicating the name of the hardware selected 180, a sort selection dropdown list 181, an information area 182, and a MagicPad™ details area 183. The MagicPad™ details area 183 includes dropdown boxes for audio zone 184, HVAC zone 185, default page 186, backlight 187, and a notes area 188. The default page 186 dropdown list allows the selection of the desired page for this MagicPad™ to initially display on startup. In this example, MP1 is the default name for the MagicPad™, as shown in the box 180. If desired, the installer enters a different name (e.g., the MagicPad™ physical location). A network ID (address) is automatically assigned by the Authoring Tool, as shown in the information box 182. The DIP switches on the MagicPad™ are also set to this address. FIG. 19 presents the window 60 of FIG. 10 for installation of the audio keypad. To add the audio keypad, the installer selects the toggle button for audio pad 67 and then selects the add button 73.

As shown in FIG. 20, in an embodiment of the present invention, the IntelliNet Wizard Form window 190 appears and dropdown lists are presented for selecting a profile for the audio keypad 191. The window 190 also includes buttons for continue without profiles 192 and continue using profiles 193, and a profiler's notes area 194. In this example, the installer selects AP Standard from the profile for audio keypad dropdown list 191, and then selects the continue without profiles button 192.

As shown in FIG. 21, a window 195 now appears. The window 195 for this customer and the added audio keypad includes toggle buttons for Control2 196, MagicPad™ 197, thermostat 198, HVAC interface 199, modem 200, J-Book 201, audio keypad 202, audio matrix 203, NetMonitor 204, PulseCounter 205, and all 206. The window 195 also includes buttons for report 207, add 208, and delete 209, a box indicating the name of the hardware selected 210, a sort selection dropdown list 211, an information area 212, and an audiopad details area 213. The audiopad details area 213 includes dropdown boxes for audio zone 213a and default page 213b, and a notes area 213c. In this example, API is the default name for the audiopad, as shown in the box 210. If desired, the installer enters a different name (e.g., the audiopad physical location). A network ID (address) is automatically assigned by the Authoring Tool, as shown in the information box 212. The DIP switches on the audiopad are also set to this address. FIG. 22 presents the window 60 of FIG. 10 for installation of a thermostat. To add a thermostat, the installer selects the toggle button for thermostat 63 and then selects the add button 73.

As shown in FIG. 23, in an embodiment of the present invention, the IntelliNet Wizard Form window 220 appears and dropdown lists are presented for selecting the number of thermostats 221 and profiles for the thermostats 222. The window 220 also includes buttons for continue without profiles 223 and continue using profiles 224, and a profiler's notes area 225. In this example, the installer selects TSTAT (Standard) from the profile for thermostat dropdown list 222, and then selects the continue without profiles button 223. The steps shown in FIG. 22 and 23 are repeated to add additional thermostats.

A window 230 then appears, as shown in FIG. 24. This window 230 provides HVAC interface details. The window 230 includes toggle buttons for Control2 231, MagicPad™ 232, thermostat 233, HVAC interface 234, modem 235, J-Book 236, audio keypad 237, audio matrix 238, NetMonitor 239, PulseCounter 240, and all 241. The window 230 also includes buttons for report 242, add 243, and delete 244, a box indicating the name of the hardware selected 245, a sort selection dropdown list 246, and an information area 247. For the thermostat, the window 230 includes a button for thermostat details 248 and a notes area 249. In this example, TSTAT 1 is the default name for the thermostat, as shown in the box 245. If desired, the installer enters a different name (e.g., the thermostat physical location). A network ID (address) is automatically assigned by the Authoring Tool, as shown in the information box 247. The DIP switches on the thermostat are also set to this address. In FIG. 24, if the user selects the thermostat details button 248, a window 255 presenting default thermostat settings appears, as shown in FIG. 25. The window 255 for this customer and the added thermostat includes a box 256 containing the default name, a cool settings area 257, a heat settings area 258, a mode selection area 259, and a notes area 260. The mode selection area 259 includes dropdown lists for mode is 259a and fan is 259b. Default values for cool settings and heat settings are automatically displayed, and the installer may change the settings using dropdown lists. FIG. 26 presents the window 90 of FIG. 12 for compiling and uploading the selected Control2. To see all of the hardware devices for the customer, the installer selects the all toggle button 101. The hardware devices entered for the customer are displayed with their names and network addresses in the information area 107. Once all the hardware is entered and correct, the installer selects the compile tab 50.

A window 265 then appears, as shown in FIG. 27. The window 265 explains that compiling is used to translate the data defined in the Authoring Tool into data that is understandable by the Control2. The Contro 12 uses a binary data format, which is optimized for size and speed. The Authoring Tool uses a large amount of data just to make it human readable. Compiling also searches for and reports many types of errors. The window 265 contains buttons for compile data 266 and edit ValuLists 267. The installer selects the compile data button 266 to compile the data.

As shown in FIG. 28, within the compiling window 265, a message bar 268 now appears that indicates that the system is "Now compiling" until complete. As shown in FIG. 29, once the compiling is complete, two additional buttons appear for send data to Control2 270 and update entire Control2 271. The installer selects the send data to Control2 button 270 for data only upload to the Control2. As shown in FIG. 30, a status window 275 appears, which displays the progress of the upload. The status window 275 also includes a cancel button 276. In FIG. 29, if the user selects the button for update entire Control2 271, data, OS, and application upload to the Control2 occurs. A status window 275, as shown in FIG. 30 appears for this selection, as well. The selection for update entire Control2 271 is used if the version of the Authoring Tool in use is different than the version used to originally upload to the Control2. The designer must have a firm grasp of the installer section of the Authoring

Tool. Given any particular installation or planned installation, the designer has the ability to modify the many objects in the relational databases and create new solutions. The designer does this through the use of various forms presented by the Authoring Tool. In addition to those forms representing "hardware objects" presented to the installer, the designer has access to several other forms that represent the many "logical objects" that affect the display and actions of the system. Object diagrams are a convention used to convey an understanding of the relationship between the various objects in a customer database. There are "hardware object diagrams," which as the name implies, represent actual physical hardware devices (nodes) in the system. For a particular customer, there is a hardware object for every node that was entered by the installer. There are also "logical objects diagrams," which represent the user interface and the programmatic logic that occurs as the system of the present invention operates in response to its environment. These logical objects diagrams cause things to happen in the system, and their results manifest themselves as audible tones, visual displays, physical actions, or some further programmatic action. When a button is pushed on a MagicPad™ or Keypad and an audible or visual event occurs, that event is the result of the interaction of logical and hardware objects.

Referring to FIG. 3, representative hardware and logical object diagrams are described. FIG. 3 is a roadmap showing how the various object diagrams interrelate. The upper portion of FIG. 3 contains hardware objects 20, and the lower section contains the logical objects 21. Arrows 22, 23, 25, and 25 shown relationships between objects.

Prior programming experience, although helpful, is not a requirement for understanding and using the designer section. Due to the virtually unlimited solutions that a designer can create, a step-by-step instructional sequence as used in the installer section does not faithfully represent the versatility and power of the designer's role. An example of a potential customer requirement and the sequence of forms used to create the solution will be used to introduce the concept of "objects" and how they relate to one another. Once this concept is understood, the designer can refer to the individual "object" descriptions 21 as shown in the roadmap (see FIG. 3) and can identify the various forms 26 that must be filled out to complete the solution. Also shown is example code information 27.

The following is a representative example of the thought process and the concepts that the designer must use to provide a solution to a customer need. Stepping through this example and using the various references give a good idea of how a designer may create future solutions. Continuing with the sample installation presented with regard to the installer above, a new customer requirement is submitted to the designer.

In this scenario, the customer's home has a basement with a sump pump system, and the customer wants a display on the MagicPad™ that will indicate if the sump pump is on or off. The designer develops a mental picture of what is involved. In some cases the solution may be complicated enough to require drawing out a representation of the solution. Starting with a firm grasp of the hardware requirements and listing the status and control requirements helps the designer identify the specific hardware and logical objects that will be created and manipulated. A digital input on the customer's Control2 must be wired to a dry contact closure in the sump pump system. This completes the hardware requirement. Next, the designer uses the Authoring Tool to create the desired solution.

Using the window 279 shown in FIG. 31, the designer locates the Control2 hardware object 280 in the upper portion of FIG. 31. A connection 281 is made to a digital input 280a on the Control2 280. The 1/0 portion of the Control2 object diagram says that there are twelve digital inputs that have variable names assigned to them ( Control2 Input 1 through 12). A line 282 leads from the Control2 object 280 to the VARS logical object diagram 283 in the lower section of FIG. 31.

The designer knows that the MagicPad™ will display the status of the sump pump. Looking at the MagicPad™ hardware object in the top section of the window 279 shown in FIG. 31, the designer can see that a line connects the "page" object diagram 283 and an arrow 284 from there points to the "button" object diagram 285. Again, information in the object diagrams themselves provides considerable help to the designer. The existing installation contains a MagicPad™. There are existing pages and buttons displayed on the MagicPad™. The designer must decide where to display the sump pump status button. Each MagicPad™ has a default page that displays when the system initializes. If the sump pump status button is important enough that the customer desires it on the default page, there must be a button free to use for display. This example assumes that there is a button available. For an embodiment of the present invention, the default page looks as shown in FIG. 32 (prior to creating and placing the new button on it).

As shown in FIG. 32, because there is a blank button 290 on this page 291 , the designer can use this spot for the new button. The sequence of steps and the forms used to perform the following tasks will now be presented: 1) create a button; 2) display sump pump status "on/off on the button; and 3) place the button on a particular page.

GUIs for the designer for an embodiment of the present invention will now be described. These GUIs are presented in FIGs. 33-37. FIGs. 33-35 present the process for a designer to navigate from the pages form to the button form. FIG. 33 presents a window 300 containing pages functions for use by a designer. The window 300 shown in FIG. 33 thus corresponds to selection of the pages tab 301. The window also includes tabs for buttons 302, routines 303, Vars 304, profiles 305, compile 306, and installer . . . 307. In addition, the window has toggle buttons for MagicPad™ 308 and 9 button keypad 309; a pulldown list 310 for selecting the page desired; buttons for add 311, delete 312, and amend 313; a delay selection 314, a message area 315, and a button navigation area 316. The designer selects a button within the button navigation area 316 for creating a new button function. The popup window 320 shown in FIG. 34 then appears. The window 320 includes a dropdown list for show 321, a list of functions 322, and buttons for design new 323, edit 324, leave blank 325, and cancel 326. The designer selects the design new button 323 to add a button function.

The window 330 shown in FIG. 35 then appears, which presents the button screen, which corresponds to the button tab 302. The window 330 includes a dropdown list 331 for selecting a button name, which appears in the edit box 331a, a notes area 332, and buttons for add 333, delete 334, display 335, press 336, release 337, and hold 338, and a button definition area 339. The MagicPad™ button default name appears in the edit box 331a. FIGs. 36-38 present the process for creating a button directly from the button form. In FIG. 36, the window 330 for buttons is presented, which corresponds to the tab for buttons, after selection of a new button. For a new button, the designer selects the add button 333, and the form automatically initializes itself for entry of information of a new button, as shown in FIG. 36. As shown in FIG. 37, the designer enters a name for the button in the edit box 331a, and enters any notes desired concerning the button in the notes area 332. The designer then places the cursor in the button to be edited 339a and clicks the left mouse button. The designer may then enter two lines of text within the button 339a, up to a set number of characters per line. This is the button text that is displayed on the actual MagicPad™. Within the button is a "@" character. The "@" character serves a special purpose. When it is placed in the button 339a, the value of the variable(s) selected to the right of the button 339b, 339c, 339d are displayed in place of the associated "@" (up to three such values).

In an embodiment of the present invention, the Authoring Tool uses variables for tracking and evaluating different values in a customer's database. Each variable has its own specific name and takes on a specific format depending upon the method that enters it in the database. Variables may be system variables that are identifiable by a name beginning with an underscore ("_ . . .") or they may be user-defined variables named by the designer/profiler. The primary differences between these two types of variables is that system variables ("_ . . .") can't be renamed or deleted, and those having names specifically beginning with "_SYS..." do not initiate any functions/routines as a result of their values changing (called an on change action).

In an embodiment of the present invention, to help build an understanding of the concept of variables in the Authoring Tool, the table shown in FIG. 38, lists the variables that are automatically entered into a customer database by the Authoring Tool as individual pieces of hardware are added to a customer by the installer.

Variables are Read Only or Read/Write. The format for these variables is predefined by the Authoring Tool. Variables have many uses, but a simple explanation of the most common uses is provided in the table shown in FIG. 4.

A change in a variable's value can be caused directly by the designer, an external stimulus such as a relay contact closure, or through some programmatic result of a routine within the Authoring Tool. The table shown in FIG. 4 lists the "direct" causes of a change in a variable due to direct access by the designer or an external stimulus. FIG. 39 contains a list of functions/descriptions. The descriptions routines, pages, and buttons below explain other changes in variables.

In an embodiment of the present invention, routines are one or more functions combined in a fashion so that they carry out the desired outcome of a designer or installer. Creating routines and identifying them by unique names allow the designer to easily use the routines over again by simply using the function "do routine" and supplying the name of the routine.

Any routine that has a name beginning with an underscore "_..." cannot be deleted or renamed. Names of this type are assigned to routines generated when the designer adds or edits function(s) designated to execute upon the physical action of pressing, holding or releasing a button on a control pad, such as a keypad or MagicPad™. Similarly, names of this type are generated for the function(s) that execute when a page timeout occurs and when certain variables (discussed below) change in value. The names are readily identifiable by the following convention: 1) "_BP..." button press; 2) "_BH..." button hold; 3) "_BR..." button release; 4) "_BD..." button display; 5) "_PT..." page timeout; and 6) "JVC..." variable change (on change). Routines can be specifically created and named by the designer/profiler for other uses. These are user routines and can be freely renamed and deleted. In an embodiment of the present invention, pages are the primary user interface that a customer uses to operate the installed system. A page is comprised of a group of buttons as defined by the designer. Control pads, such as MagicPads™ and keypads, are the physical portion of the interface, and pages are the logical portion of the interface. As shown in FIG. 31, the physical and logical separation of devices can be seen in the object diagrams. Control pad, such as MagicPad™ or keypad, object diagrams are in the upper (hardware) section and pages and buttons are in the lower (logical) section. Buttons are discussed in more detail below.

The designer uses several pages to create a menu driven system that a customer navigates through to get information from and operate the installed system. FIG. 40 illustrates a sample of a simple menu for an embodiment of the present invention. Given that a virtually infinite number of pages could be designed, there is the potential to make the menu system very large with several layers. It is the designer's job to use some human engineering philosophy in the overall design of pages and the menu. Keeping the number of layers to a minimum and presenting the user with the most frequently used buttons in the upper layer pages of the menu is a primary consideration in designing a system.

In an embodiment of the present invention, buttons are logical objects created by the designer that give the customer discrete user interface display and control options over the installed system. Once a button has been designed and placed on a page for display on a control pad, such as a MagicPad™ or keypad, the user can receive information about the system through visual and audio response. The user can also cause some programmatic action and resultant response in the system by pressing, holding, or releasing the physical button to which the designer has assigned the logical button.

As described above with regard to pages, pages are made up of a collection of buttons. In the case of a MagicPad™, a single page can display up to six buttons.

Several pages can be designed into a menu system that users navigate through in order to receive information and control the system.

Once a button has been designed, it is available for placement on any page that the designer wants. Building on the diagram used in the previous section on pages, a star highlights an identical logical button that was placed on three separate pages. In

FIG. 41, the logical button was placed in the same position on each of the pages, but it could have easily been placed anywhere the designer wanted.

What the button displays and what programmatic action may be performed when a user presses, holds, or releases the physical button is also part of the designer's role. The designer uses variables, functions, and routines to create those programmatic actions. In the simple menu shown in FIG. 41, if the starred button is pressed, the page displayed returns to the top of the menu.

FIG. 42 presents an overview of the various hardware environment definitions and GUI windows functions for an embodiment of the present invention. Description of the GUI for another embodiment of the present invention will now be presented. This embodiment of the present invention further includes of a series of related database tables and forms that allow the user to work with the data in these tables. Many of the details of these database tables are hidden from the view of the user by the forms. In this embodiment of the present invention the forms used by the Authoring

Tool of the system are divided into three major sections, as follows. The first section is called installer. The installer configures a system for final installation. This section is used to describe the physical layout of the system. The installer describes the system to the Authoring Tool, and the Authoring Tool tells the installer how to set up the addresses for the network devices. Additionally, the Authoring Tool configures the operation of the various keypads based on defaults for the attached devices, as defined by the profiler. The installer needs only rudimentary computer skills.

The second section is called designer. The designer can customize any aspect of a database. The designer uses both installer and designer tools in order to lay out a system's hardware components, as well as its software configuration. A configuration modified by the designer can be saved as an individual customer's data or may be used as a default system configuration. Default configurations are useful if the service provider has one or more standard offerings that will be implemented across many customers. The third section is called profiler. The profiler defines the user interface for a device to be connected to the system. The data defined by the profiler will be applied next time an installer adds the profiled device. The profiling is used to allow each service provider to create their own unique solutions for their marketplace. Once this process is done for each potential attached device, the installers automatically duplicate this solution by just point and click.

Each of these sections is divided into several sub sections, as described below. FIG. 43 presents a window 400 of a GUI for an embodiment of the present invention. The window 400 shown in FIG. 43 presents the information corresponding to the customer tab 401. Other tabs for this window 400 include installer 402, designer 403, IR comp profiles 404, and compile 405. The window 400 for the customer tab 401 includes boxes 406 for adding customer information, including last name, first name, number, street, city, state, zip code, phone, install date, and installer; a box 407 for notes; and buttons for load & edit 408, save 409, add 410, delete 411, find 412, and print command manual 413.

The Authoring Tool objects database forms are used to define objects that build a control system. These objects are related to one another in three possible ways: 1) directly linked — a field in the object is pointing to another object; 2) action ~ an action being executed performs a function on an object; and 3) indirect action ~ an action uses a parameter starting with "CURJIENT". This indirectly points to the current object of the suffix type (i.e., " CURRENT BUTTON" or "CURRENT PAGE").

FIG. 44 presents the fields in a node object 420. This is representative of the object descriptions of this embodiment. All objects start with a short description 421 of the object's purpose. Data 422 includes all parameters of an object's description other than links (pointers) 423 to other database objects. Any special information is included in the notes section 424.

Forms, like the one shown in FIG. 45 are representative of what the user sees when the Authoring Tool is used. The installer objects comprise the data required for final installation of the system. The installer is shielded from the higher level details of the system to which the designer and profiler have access. As the installer works to configure the system, data designed by both the designer and the profiler are seamlessly merged into the customer's database.

The form shown in FIG. 45 includes a window 430 for the selected tab for hardware 431. Other tabs include audio . . . 432, security 433, HVAC 434, XI 0 435, and return from installer . . . 436. The window 430 also includes buttons for add new 437, delete 438, and initialization action 439; a dropdown menu for filter 440; input boxes for name 441, location 442, and installer notes 443; and a display area 444. The node object defines the physical layout of the system. As the installer adds node objects via the applicable form, other objects are automatically created by the application based on defaults set up by the designers and profilers. In an embodiment of the present invention, a node object is required for every device connected to the system. The node object contains the hardware object's network ID, type of device, and pointers to other objects. Node objects can be viewed as individual device identities, such as MagicPad™ or modem

Given a specific installation plan, the installer knows the quantities and locations of the various network devices (nodes). This is referred to as the installer methodology. In the installer section of the Authoring Tool, the installer adds applicable devices in any order: 1) Control2; 2) audio matrix(s); 3) security panel; 4) audio and security keypads; 5) MagicPads™; and 6) in any order, modem, HVAC, and

XI 0 devices.

The Authoring Tool automatically assigns network addresses, and the configuration and operation of the various keypads are automatically set up based on defaults. The installer, using the forms provided in the installer section, enters specific data for each of the network devices.

In an embodiment of the present invention, the system always contains a control device, such as Control2. If an audio matrix is in the system, the installer must use the audio source and audio zone forms to further define the system. In keeping with the convention already mentioned, these forms allow the installer to manipulate the databases (objects) via the entry of data items, selection of actions and the selection of certain pointers to other objects.

FIG. 46 presents the input window 450 for the audio sources (ASources) tab 450a for an embodiment of the present invention. Tabs for other windows include audio zones (AZones) 450b and return from AUDIO . . . 450c. The window 450 includes buttons for adding 451 and deleting 452 sources and for initialization action

453, connection action 454, disconnect action 455, next press action 456, hold action

457, merge all components from component database 458, and merge component from component database 459. The window 450 also includes an input area 460 for sources, and dropdown lists for component 461, IR port 462, and power sensing via

463.

FIG. 47 presents the input window 470 for the audio zone tab 450b. The window 470 includes a data entry area for audio zones 471, including name, matrix, and port information; entry boxes for zone information 472, including zone location and zone group; and entry boxes for volume, bass, and treble 473, including turn on, maximum, maximum switch, minimum switch, bass, and treble.

The security node contains the data required to set up the security definitions of the installation. A security window 480 for an embodiment of the present invention is presented in FIG. 48. Security information corresponds to the tab for security 483. Other tabs for the security window 480 include hardware 481, audio . . . 482, HVAC 484, XI 0485, and return from installer . . . 486.

The HVAC node contains the data required to set up the normal and set back features for the installation. The HVAC window 490 is presented in FIG. 49. The window 490 corresponds to the tab for hardware 431. Other tabs include audio . . . 492, security 493, HVAC 494, XI 0 495, and return from installer . . . 496. The window 490 includes buttons for add 497 and delete 498; input areas for HVAC zones, including a dropdown list for select a HVAC zone 499, input areas for enter or change name 500, enter or change comment 501, and an installer manual 502; and input areas for zone details, including thermostat type 503, hardware interface details, including network node 504 and sub ID 505, default primary settings 506, including cool at, heat at, cool at minus heat at minimum, mode is, and fan is, and default setback settings 507, including cool at, heat at, cool at minus heat at minimum, mode is, and fan is. The XI 0 object contains the data required to organize the XI 0 controls in the installation. FIG. 50 shows the window 510 for XI 0 controls, which corresponds to the tab for XI 0 510e. Other tabs include hardware 510a, audio . . . 510b, security 510c, HVAC 510d, and return from installer . . . 51 Of. Two input areas, for XI 0 devices 511 and XI 0 actions 512, are included in the window 510. The XI 0 devices area 511 includes buttons to add 513 and delete 514, and an input area 517; the X 10 actions area 512 includes buttons for add 515 and delete 516, and an input area 518. The window 510 also includes a button for set routine 519 and toggle buttons for on 520, off 521, bright 522, and dim 523.

The modem object contains the data required to establish the query and response system for the installation. FIG. 51 presents the window 525, corresponding to the hardware tab 525a, for network hardware nodes for a modem. The window 525 includes a section for network hardware nodes 526, which includes buttons for add 527 and delete 528, a dropdown list for filter 529, and input areas for name 530 and location 531, and an information area 532; a section for defaults, which includes input boxes for dial setup 534, phone # 535, hangup 536, retries 537, and timeout 538; a section for script pages, which includes buttons for add 539, delete 540, and action 541; an input string area 543, which includes string and variable; and a manual information area 544.

The designer objects contain the data required to customize any aspect of the database in an installed system. Modification to a system configured by an installer or the creation of entirely new pages, buttons, routines, and variables is possible in the designer mode. In the designer, there are many forms that control and create the objects and modify the databases. The designer utilizes all of these forms plus the tools in the installer.

The page object allows the designer to combine buttons and other user interfaces to define the characteristics of a MagicPad™. Predefined pages can be selected and modified as well as created. Display characteristics such as backlighting and text are selectable. The keypad buttons are predefined and not displayed on the page object as the MagicPad™ is, however the principle behind the buttons on the keypads is similar. FIG. 52 presents a page object. FIG. 52 contains a window 550 corresponding to the pages tab 550a; other tabs include buttons 550b, routines 550c, Vars 550d, and return from designer . . . 550e. The window 550 includes an input area for pages 551, containing buttons for add 552 and delete 553, a dropdown list for select a page 554, an input area for enter or change name 555, and an input area for enter or change comment 556; a buttons viewing area 557; a scrolling text field on bottom right button input area 558; and a timeout button 559 with a timeout seconds input 560.

The button object defines the specifics of the particular button for those devices that have them, such as the MagicPad™, audio keypad, and security keypad. Each button is unique in its name and in the various functions that are performed by the press, hold, or release of the particular button. It is important to remember that there is a relationship between the various objects. In a hypothetical situation, a designer may want to modify the text and action for a particular button on a certain page of a MagicPad™. The page form allows the designer to, for example, select a button that points to the button object and brings up the button form. Now the designer can create/modify the routines that the button initiates when displayed, pressed, released, or held. By selecting the press function on the button form, the designer is led to the next object for discussion, which is the routine form.

FIG. 53 presents a button window for an embodiment of the present invention. In FIG. 54, the window 565 corresponds to the tab for buttons 565b; other tabs include pages 565a, routines 565c, Vars 565d, and return from designer . . . 565e. The window 565 includes a button area 566, which contains buttons for add 567 and delete 568, dropdown lists for set a filter 569 and select a button 570, an input area for enter or change name 571 , and an input area for enter or change comment 572; a button name area 573; input area for text 574, variables 575, and default LED and backlight 576, which includes toggles for off, R, G, A, leave alone, and blink; and a function area 577, containing buttons for display 578, press 579, release 580, and hold 581, and inputs for repeat press command 582 and rate x 0.01s 583.

The corresponding object diagram for a button is shown in FIG. 53A. The object diagram includes the name of the object diagram 585, description 586, data 587, pointers 588, actions 589, and notes 590.

The routine object allows the designer to select from many common actions that have already been developed in the Authoring Tool or allows the designer to create unique routines to provide a solution to the requirement at hand. FIG. 54 presents the window 600 for routine, corresponding to the tab 600c for routines; other tabs include pages 600a, buttons 600b, Vars 600d, and return from designer 600e. The window 600 includes a section for routines 601, containing buttons for add 602 and delete 603, dropdown list for show 604, and information area 605; an information area for legends for routines 606; and a button for edit functions 607. The corresponding object diagram for a button is shown in FIG. 54A. The object diagram includes the name of the object diagram 610, description 611, data 612, pointers 613, and notes 614.

Functions are the building blocks for all of the previously developed routines and can be used singularly or in combination to create other routines. The actions that the functions take may be dependent upon constants and variables. The various forms and the representative object diagrams used in the functions activity are shown in FIGs. 55-57A.

FIG. 55 shows the window 620 for a function edit routine. The window 620 includes a section for current command 621, and a section for function selector 622. The function selector section 622 includes a dropdown list for category 623, a button for OK 624, a list of functions 625, and a descriptions information window 626. The corresponding function object diagram is shown in FIG. 55A. The object diagram includes an area for name 630, description 631, data 632, actions 633, pointers 634, and notes 635.

FIG. 56 shows an edit routine window 640. The window 640 includes an information area 641, a conditional expression if variable section 642, and a third area 643 that includes function arrow buttons 644, 645, a delete button 646, an add button 647, and input areas for change function from, MagicPad™, and level; and a print routine button 648.

FIG. 57 presents a window 658 for variables (Vars), corresponding to the tab for Vars 650d; other tabs include pages 650a, buttons 650b, routines 650c, and return from designer 650e. The window 650 contains a section for variables, which includes buttons for add 652 and delete 653, dropdown lists for filter 654 and find a variable 655, and input areas for variable name 656 and comments 657; a section for value 658, including input areas for minimum, maximum, default, and current string; a section for format 659, including toggle buttons for numeric, hh:mm, %, $, mm/dd/yy, degree F, string, and value list; and an action button for on change routine 660. The corresponding object diagram for variables is shown in FIG. 58 A. The object diagram includes an area for name 665, description, 666, data 667, actions 668, pointers 669, and notes 670. APPENDIX: AUTHORING TOOL ALPHABETICAL FUNCTION LISTING

ADD VARS

Adds two variables of numeric type and stores the result in ResultVar. Valid variable types include: numeric, time, date, percent, degrees, and dollars. Parameter 1 = first variable. Parameter 2 = second variable. ResultVar = Parameter 1 + Parameter 2

AP NEXT PRESS

Activates the Next Press action assigned to a source within the selected Audio Zone. This action can be the "Press" actions or the "Hold" action.

Parameter 1 = the Audio Zone pertaining to the Next Press action.

Parameter 2 = the type of action desired (Press or Hold). (The Press and Hold actions are defined on the Installer/ASource tab.)

AP SET SRC

Sets an Audio Matrix Zone to a source and performs the initialization action for that source. If the source is currently in use by another zone, the connect action will be performed.

Parameter 1 = the Audio Zone to change.

Parameter 2 = the input (source) to select. (Initialization and Connect actions are defined on the Installer/ASource tab.)

BACKLIGHT

Turns an individual button's backlight On or Off.

Parameter 1 = the Button to change.

Parameter 2 = the state to set the backlight (On or Off). BACKLIGHT LEVEL

Sets the backlight level of a MagicPad™ to an intensity level using numeric values between 0 (Off) and 15 (Full On).

Parameter 1 = MagicPad™ to change. Parameter 2 = desired Intensity Level.

DEBUG

DEBUG w/CR-LF

DECVAR

Decrements a variable of numeric type. Valid variable numbers include: numeric, time, date, percent, degrees, and dollars.

Parameter 1 = a numeric style or list variable. Parameter 2 = an amount to decrement.

DELAY

Delays the current routine for a defined time period. All other active routines are unaffected. Parameter 1 = minutes.

Parameter 2 = seconds.

DIVIDE VARS

Divides two variables of numeric type and stores the result as Result Var. (whole integers only). Valid variable types include: numeric, percent, time date, dollars, and degrees.

Parameter 1 = variable 1.

Parameter 2 = variable 2. DO ROUTINE

Branch the program flow to the named routine. If Parameter _2 = 0, the named routine is processed and following statements are processed upon completion of the named routine. If Parameter 2 > 0, statements following the Do Routine command are processed immediately, and the named routine is executed after the delay in Parameter_2 expires.

Parameter 1 = routine to execute.

Parameter 2 = seconds until routine executes.

EXIT

Exit the routine and ignore all subsequent statements in the current routine (i.e., if ResultVar = 2, EXIT).

GET PULSE COUNT

GOTO DEFAULT

Takes the addressed MagicPad™ to its default page.

Parameter 1 = the MagicPad™ to affect. (The Default Page is defined in the Installer/Node tab.) (_Current_Keypad refers to the keypad responsible for the executing command and should only be used with "Press," "Hold," and "Release" commands.)

GOTO PAGE

Goto a new page on the MagicPad™ addressed in the first Parameter. Parameter 1 = the MagicPad™ node to affect.

Parameter 2 = the page to navigate to. (_Current_Keypad affects the keypad that initiated this command and should only be used with "Press," "Hold," and "Release" commands.)

INCDAY INCMONTH

Increments month variable by 1 or -1.

Parameter 1 = date variable to increment.

Parameter 2 = amount to increment (1 or -1).

INC VAR

Increments a variable of numeric type. Valid variable types include: numeric, time, date, percentage, dollar, and degrees.

Parameter 1 = a numeric style of list variable. Parameter 2 = an amount to increment.

INC YEAR

Increments year variable. Parameter 1 = date variable to increment. Parameter 2 = amount to increment date variable (1 or -1).

IRFUNC

IRNUMERIC

IR SOURCE CONTROL

Used to issue an IR command to a specific audio source, as defined in the Installer/ASource tab.

Parameter 1 = the audio source that is to receive the command. Parameter 2 = the command to be issued (as defined in IR_Comps).

LED COLOR

Changes the color of an individual button's LED.

Parameter 1 = the button for which the LED should be changed. Parameter 2 = the color that the button's LED should be.

(All non- MagicPads™ use "Off and "Green" only.) MOD VARS

Calculates the Modulos of two variables of numeric type and stores the result in "ResultVar". Parameter 1 = the variable to equate.

Parameter 2 = the modulos variable.

MODEM DIAL

MODEM HANGUP

MULTIPLY VARS

Multiplies two variables of numeric type and stores the result in "ResultVar". Valid variable types include: numeric, percentage, degrees, and dollars. Parameter 1 = variable 1.

Parameter 2 = variable 2.

RAMP BASS

Raises or lowers the Bass level of an Audio Matrix audio zone. Parameter 1 = the audio zone to be adjusted.

Parameter 2 = the direction to Ramp Bass (Up or Down).

RAMP TREBLE

Raises or lowers the Treble level of an Audio Matrix audio zone. Parameter 1 = the audio zone to be adjusted.

Parameter 2 = the direction to Ramp Treble (Up or Down).

RAMP VOLUME

Raises or lowers the volume of an Audio Matrix audio zone. Parameter 1 = the audio zone to be adjusted.

Parameter 2 = the direction to Ramp Volume (Up or Down). RELAY PULSE

Pulses a relay for the desired amount of time. Parameter 1= the relay to be pulsed. Parameter 2 = the duration of the pulse in .01 second intervals.

Pulse = Toggle (Delay) Toggle

RELAY SET

Sets a relay to the desired state. Parameter 1 = selects the relay to set.

Parameter 2 = selects the desired state. (1 = Closed; 0 = Open.)

RELAY TOGGLE Toggles a relay from one state to another. If closed, it will open; if open, it will close.

Parameter 1 = the relay to be toggled.

SET BASS Sets the bass level of an Audio Matrix audio zone to the level contained within the Parameter 2 variable.

Parameter 1 = the audio zone to be set. Parameter 2 = the variable used to store the level.

SET SOURCE

Sets the selected audio zone to a source defined by the Parameter 2 variable and executes the source initialization or connect actions as defined in Installer/ASource tab.

Parameter 1 = the audio zone to be changed. Parameter 2 = the variable used to Set Source. (If the source is not in use in another audio zone, the initialization action is used. If the source is in use, the connect action is used.)

SET TIME Used to set a variable to the current time/date settings.

Parameter 1 = the variable to be changed to current time. Parameter 2 = the variable to be changed to current date.

SET TREBLE Sets the Treble level of an Audio Matrix audio zone to a level contained within a variable.

Parameter 1 = the audio zone to be set. Parameter 2 = the variable used to store the level.

SET VAR NUM

Sets a variable to a number. Valid variable number types include: numeric, time, date, percent, degrees, and dollars. Parameter 1 = a numeric variable. Parameter 2 = a number.

SET VAR STR

Sets a variable of a type string to a new string. Parameter 1 = variable of type string. Parameter 2 = a string of 12 or less characters.

SET VAR VALUE

Sets a variable of type List to a specific value. Parameter 1 = variable of type List. Parameter 2 = value from the variable's list. SET VAR VAR

Equates 2 variables of same type. Parameter 1 = the destination variable. Parameter 2 = the source variable. (Parameter 1 and Parameter 2 must be of the same type.)

SET VOLUME

Sets the Volume of an Audio Matrix audio zone to the level stored within a variable. Parameter 1 = the audio zone to be adjusted.

Parameter 2 = the variable used to store the level.

SET PULSE COUNT

SET PULSE MASK

SET PULSE ROLL

SMART UPDATE This command is for engineering use only. The command checks the current MagicPad™ button contents and compares them with the updated contents only refreshing changes.

Smart = refreshes ONLY changed content. Dumb = changes all content regardless of change. (Smart reduces network traffic)

SUB VARS

Subtracts two variables of numeric type and stores the result in "ResultVar". Valid variable types include: numeric, time, date, dollars, percent, and degrees. Parameter 1 = Variable 1.

Parameter 2 = Variable 2. TOGGLE VAR

Toggles a list variable through all list elements. Parameter 1 = a list variable.

X10 ALLOFF

Issues an X-10 off command, signaling all units within the selected house code to turn off.

Parameter 1 = HC-House Code (Value 1-16). (Requires TW 523 interface.)

X10 ALLON

Issues an X-10 command signaling all modules within the selected house code to turn on. Parameter 1 = HC-House Code (Value 1-16)

(Requires TW 523 interface.)

XI 0 BRIGHT

Issues an X-10 Bright command to all modules set on selected house codes and unit codes.

Parameter 1 = HC-House Code (Values 1-16).

Parameter 2 = UC-Unit Code (Values 1-16). (Requires TW 523 interface)

XI 0 DIM

Issues an X-10 Dim command to all modules set on selected house codes and unit codes.

Parameter 1 = HC-House Code (Values 1-16).

Parameter 2 = UC-Unit Code (Values 1-16). (Requires TW 523 interface) XI 0 OFF

Issues an X-10 off command to all modules set on selected house codes and unit codes.

Parameter 1 = HC-House Code (Values 1-16). Parameter 2 = UC-Unit Code (Values 1-16).

(Requires TW 523 interface)

X10 ON

Issues an X-10 On command to all modules set on selected house codes and unit codes.

Parameter 1 = HC-House Code (Values 1-16).

Parameter 2 = UC-Unit Code (Values 1-16). (Requires TW 523 interface)

Claims

CLAIMS: L A method for a user to configure a programmable control system, comprising: a. coupling a terminal having a control system database to the programmable control system, wherein the programmable control system is programmable by a control system program and is coupled to devices and interfaces; b. inputting to the terminal a list of devices and interfaces connected to the programmable control system; c. automatically presenting the user with a plurality of functions to associate with the connected devices and the connected interfaces; d. the user selecting functions to associate with each of the devices and interfaces in the inputted list of connected devices and interfaces; e. automatically compiling a control system program, wherein the control system program associates the selected functions with each of the devices and interfaces in the inputted list of connected devices and interfaces; and f. automatically downloading the compiled control system program from the terminal to the programmable control system, such that the programmable control system is programmed, wherein a-f are not order dependent.

2. The method of claim 1 wherein the terminal comprises a personal computer.

3. The method of claim 1 further comprising: automatically presenting the user with a database containing at least one customer profile, wherein each of the at least one customer profile includes at least one associated customer specific function; and the user selecting a customer profile from the database; wherein the plurality of functions automatically presented to the user in c automatically includes the at least one associated customer specific function for the selected customer profile.

4. The method of claim 3 wherein the user includes one from the group of an installer, a designer, and a profiler.

5. The method of claim 4 further comprising: if the user includes one from the group of a designer and a profiler, automatically providing the user with an option to add a function for the selected customer; if the user selects the option to add a function to the plurality of functions for the selected customer, automatically providing the user with a template for defining the added function; automatically providing the user with template for associating the defined function with one from the group of the connected devices and connected interfaces.

6. The method of claim 4 further comprising: if the user is a profiler, automatically providing the user with an option to add a new function to the selected customer profile; if the user selects the option to add a new function to the selected customer profile, automatically providing the user with a template for defining the new function; and automatically adding the new function to the at least one associated customer specific function for the selected customer profile; wherein the plurality of functions automatically presented to the user in c automatically includes the new function for the selected customer profile.

7. The method of step 3 further comprising: automatically presenting the user with an option to add a customer; if the user selects to add a customer, automatically presenting the user with input prompts to complete the added customer's customer profile; and automatically adding the customer and the customer profile for the added customer to the database containing at least one customer profile.

8. The method of step 3 further comprising: automatically presenting the user with an option to delete a customer; if the user selects to delete a customer, automatically presenting the user with confirmation to delete the customer; and if the user confirms to delete the customer, automatically deleting the customer and the customer profile for the deleted customer from the database containing at least one customer profile.

9. The method of step 3 further comprising: automatically presenting the user with an option to search for a customer; if the user selects to search for a customer, automatically presenting the user with input prompts for a query to search for the customer; automatically searching for the customer based on the query; and if the customer is identified based on the query, automatically presenting the identified customer to the user, wherein the plurality of functions presented to the user in step c automatically includes the at least one associated customer specific function for the customer profile for the identified customer.

10. The method of claim 7 further comprising: automatically presenting the user with an option to import data for a customer; if the user selects to import data for the customer, automatically prompting the user for a location for the import data; inputting the location for import data; and automatically importing data for the new customer.

11. The method of claim 4 further comprising: automatically presenting the user with an option to export data for a customer; if the user selects to export data for the customer, automatically prompting the user for a location to which to export data; inputting the location to which to export data; automatically prompting the user to select data to export; selecting data to export; and automatically exporting data to the location inputted.

12. The method of claim 1 , wherein the control system database includes a manual, further comprising: automatically presenting the user with an option to print the manual; and if the user selects to print the manual, automatically printing the manual.

13. The method of claim 1 wherein the devices and interfaces comprise at least one from the group of Control2, MagicPadΓäó; thermostat, HVAC interface, modem, J-Book, audio keypad, audio matrix, NetMonitor, and Pulse Counter.

14. The method of claim 1 further comprising the step of automatically assigning a network address to each of the inputted devices and interfaces.

15. The method of claim 1 wherein the step of automatically compiling the control system program further comprises the step of automatically presenting the user with options to send data to the control unit, to update the control unit, to compile data, and to edit ValuLists.

16. A system for a user to configure a programmable control system, comprising: means for coupling a terminal to the programmable control system; means for inputting devices and interfaces connected to the programmable control system; means for automatically presenting the user with a plurality of functions to associate with the connected devices and the connected interfaces; means for the user selecting functions to associate with the connected devices and interfaces; means for automatically compiling a control system specific program associated the selected functions with the connected devices and interfaces; and means for automatically downloading the compiled control system specific program from the terminal to the programmable control system, such that the programmable control system is programmed.

17. A medium for storing a program for displaying a selected image, the

program:

a. coupling a terminal having a control system database to the programmable control system, wherein the programmable control system is programmable by a control system program and is coupled to devices and interfaces; b. inputting to the terminal a list of devices and interfaces connected to the programmable control system; c. automatically presenting the user with a plurality of functions to associate with the connected devices and the connected interfaces; d. the user selecting functions to associate with each of the devices and interfaces in the inputted list of connected devices and interfaces; e. automatically compiling a control system program, wherein the control system program associates the selected functions with each of the devices and interfaces in the inputted list of connected devices and interfaces; and f. automatically downloading the compiled control system program from the terminal to the programmable control system, such that the programmable control system is programmed, wherein a-f are not order dependent.