Automated Point Mapping Interface

Abstract

An interface is disclosed that allows a controller wiring diagram to be automatically created by understanding the nature of the building the controller is in as well as understanding the nature of the devices that are to be wired to it, and the location within the building of the devices. Users, using the user interface, can modify a depiction of the wiring diagram which may further modify the hardware of the controller device interface. Some embodiments further comprise modules that plug into the controller. The modules comprise the device connector that will be wired to the device. Some modules have hardware and memory that allow the module to physically modify the device connectors.

Description

RELATED APPLICATION

The present application hereby incorporates by reference the entirety of, and claims priority to, U.S. Provisional Patent Application Ser. No. 63/070,460 filed 26 Aug. 2020.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF DISCLOSURE

The present disclosure relates to controller point maps, and more particularly to interfaces allowing users to determine controller configuration.

BACKGROUND

Today's “smart buildings” aren't smart at all just connected. Expensive cloud add-ons that promise to “un-dumb” your control system can only provide low-value results and reduced reliability, all at the cost of more integration effort. Almost all building controls today are model-free. The model-free approach, while simple to implement, becomes quite difficult to manage and optimize as the complexity of the system increases. It also lacks the inherent self-knowledge to provide new approaches to programming, such as model-driven graphical programming, or to govern the interconnections between components and sub-system synergistics. Digital model based approaches to date have been limited in scope and specific to known models defined a-priori. They have thus lacked the ability to enable users to create complex systems of interconnected building zones by ad hoc means, use simple graphical user interfaces to define a system, or enable a digital system model to automate creation and easy updating of point mapping diagrams between devices and the controllers they will be wired to. Because of this, point mapping wiring diagrams take hours to create, as they cannot access information contained in other separate systems. Further, if a problem comes up when building a structure that requires that a wired device must be moved, the point mapping diagram must be recreated from scratch, which can entail quite a bit of effort.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section.

In embodiments, a controller is disclosed, the controller having a device interface, computer hardware, programmable memory, a user interface, a physical structure representation in programmable memory, and a list of predefined device models in programmable memory, the predefined device models having corresponding device terminal interface attributes, and device names; displaying the list of predefined device models on the user interface; displaying at least a portion of the physical structure representation on the user interface; the controller accepting a device model from the list of predefined device models displayed on the user interface; the controller accepting placement of the device model into a location in the physical structure representation; the controller accepting mapping a device terminal interface attribute associated with the device module to the device interface; and the controller using the computer hardware and programmable memory to create a control system topology comprising a point mapping diagram of the controller and the device model.

In embodiments, the device interface further comprises a device interface value and further comprising, when the device interface value and the device terminal interface attribute do not match, the controller uses a program stored in programmable memory to change the device interface value to the device terminal interface attribute.

In embodiments, the controller is operationally able to accept change in device interface value from user input.

In embodiments, at least a portion of the control system topology is displayed on the user interface.

In embodiments, a module connects to the controller and wherein the device terminal interface attribute matches the device interface value associated with the module.

In embodiments, change of the device interface value associated with the module is accepted, the change comprising operationally registering a selection from a predefined list of device terminal interface attributes stored in the programmable memory, and wherein the controller recreates the control system topology using the selection.

In embodiments, the device interface is wired to a device creating a wired device, and where the controller is operationally able to detect a fault in the wired device.

In embodiments, the controller accepting mapping the device terminal interface attribute to the device interface further comprises the controller signaling to the module to modify the module's device terminal.

In embodiments, at least a second controller and wherein the user interface is configured to allow a user to input a request to move the device model to a different location on the second controller, and wherein the request rebuilds the control system topology.

In embodiments, a controller is disclosed, the controller having a device connector, a processor, programmable memory, a user interface, a physical structure representation in programmable memory, a list of predefined device models in programmable memory, predefined device models in the list having corresponding device terminal interface attributes, and a physical structure representation in programmable memory; a program residing in memory, the program allowing input of controller information and modification of controller terminals, including instructions residing in the memory, which are executable by the processor to perform a method which includes: displaying the list of predefined device models on the user interface; the controller accepting a device model from the list of predefined device models displayed on the user interface; the controller accepting placement of the device model into a location in the physical structure representation; the controller accepting mapping a device terminal interface attribute associated with the device model to the device interface; and the controller using the processor and programmable memory to create a control system topology comprising a point mapping diagram of the controller and the device model within a representation of the controller.

In embodiments, a second controller is disclosed, and the user interface is configured to allow a user to input a request to move at least one of the predefined device models to the second controller, and wherein the second controller rebuilds the point mapping diagram.

In embodiments, a second device interface is disclosed, and the controller accepts, from the user interface, device placement on the second device interface.

In embodiments, the controller modifies the Device Connector to match requirements of the device model.

In embodiments, the controller is operationally connected to a module, the module comprises a device connector, and wherein the module modifies the Device Connector to match requirements of the device model.

In embodiments, the module modifies the Device Connector by activating a chip.

In embodiments, the module modifies the Device Connector by deactivating a chip.

In embodiments, a controller constraint, and wherein the controller constraint at least partially determines device placement within the controller.

In embodiments, a controller-module-device hierarchy with first controller and a second controller is disclosed, and a device associated with a first controller can be moved to be associated with the second controller.

In embodiments, the controller constraint comprises a labor vs equipment cost constraint or a fill rate constraint.

In embodiments, a computer-readable storage medium is disclosed, the computer-readable storage medium is configured with data and with instructions that upon execution by at least one processor in a controller computing system having a device interface, computer hardware, programmable memory, a user interface, a physical structure representation in programmable memory, and predefined device models in programmable memory, the predefined device models having corresponding device terminal interface attributes, and device names; will cause the at least one processor to perform a technical process for point mapping diagram creation, the technical process comprising: displaying the list of predefined device models on the user interface; displaying at least a portion of the physical structure representation on the user interface; the controller computing system accepting a device model from the list of predefined device models displayed on the user interface; the controller computing system accepting placement of the device model into a location in the physical structure representation; the controller computing system accepting mapping the device terminal interface attribute to the device interface; and the controller computing system using the computer hardware and programmable memory to create a control system topology comprising a point mapping diagram of the controller computing system and the predefined device model.

These, and other, aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. The following description, while indicating various embodiments of the embodiments and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions or rearrangements may be made within the scope of the embodiments, and the embodiments includes all such substitutions, modifications, additions or rearrangements.

BRIEF DESCRIPTION OF THE FIGURES

Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

FIG. 1 depicts a functional block diagram showing an exemplary embodiment of a controller in conjunction with which some described embodiments can be implemented.

FIG. 2 depicts an exemplary block diagram of a controller—module—device interface in accordance with one or more implementations.

FIG. 3 depicts an exemplary block diagram of a module in accordance with one or more implementations.

FIG. 4 depicts a flow chart of a method to create a point map interface in accordance with one or more implementations.

FIG. 5 depicts an exemplary screenshot of a physical structure representation in accordance with one or more implementations.

FIG. 6 depicts an exemplary block diagram of a relationship between a device terminal interface attribute and a device interface in accordance with one or more implementations.

FIG. 7 depicts an exemplary screenshot of a controller I/O setup representation in accordance with one or more implementations.

FIG. 8 depicts an exemplary screenshot that allows a user to place controllers and/or allow a controller computer system to place controllers automatically in accordance with one or more implementations.

FIG. 9 depicts an exemplary screenshot of a controller automatic layout that allows users to choose controller placement scenarios.

FIG. 10 depicts a controller-module-device hierarchical view in accordance with one or more implementations.

FIG. 11 depicts a controller-module-device hierarchical view with multiple controllers in accordance with one or more implementations.

FIGS. 12-13 depict exemplary screenshots of a controller I/O setup representation in accordance with one or more implementations.

FIGS. 14-20 depicts exemplary screenshots of controller I/O setup representations in accordance with one or more implementations.

FIGS. 21-22 depicts exemplary module circuit board representations in accordance with one or more implementations.

Corresponding reference characters indicate corresponding components throughout the several views of the drawings. Skilled artisans will appreciate that elements in the FIGURES are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments.

Corresponding reference characters indicate corresponding components throughout the several views of the drawings. Skilled artisans will appreciate that elements in the FIGURES are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments.

DETAILED DESCRIPTION

Disclosed below are representative embodiments of methods, computer-readable media, and systems having particular applicability to point mapping interfaces. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present embodiments. It will be apparent, however, to one having ordinary skill in the art that the specific detail need not be employed to practice the present embodiments. In other instances, well-known materials or methods have not been described in detail in order to avoid obscuring the present embodiments. “one embodiment”, “an embodiment”, “one example” or “an example” means that a particular feature, structure or characteristic described in connection with the embodiment or example is included in at least one embodiment of the present embodiments. Thus, appearances of the phrases “in one embodiment”, “in an embodiment”, “one example” or “an example” in various places throughout this specification are not necessarily all referring to the same embodiment or example. Modifications, additions, or omissions may be made to the systems, apparatuses, and methods described herein without departing from the scope of the disclosure. For example, the components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses disclosed herein may be performed by more, fewer, or other components and the methods described may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

In addition, it is appreciated that the figures provided herewith are for explanation purposes to persons ordinarily skilled in the art and that the drawings are not necessarily drawn to scale. To aid the Patent Office and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims or claim elements to invoke 35 U.S.C. 112(f) unless the words “means for” or “step for” are explicitly used in the particular claim.

Embodiments in accordance with the present embodiments may be implemented as an apparatus, method, or computer program product. Accordingly, the present embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module” or “system.” Furthermore, the present embodiments may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out operations of the present embodiments may be written in any combination of one or more programming languages.

The flowchart and block diagrams in the flow diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus.

Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). “Program” is used broadly herein, to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (who are also referred to as developers) and/or automatically generated. “Optimize” means to improve, not necessarily to perfect. For example, it may be possible to make further improvements in a program or an algorithm which has been optimized.

The technical character of embodiments described herein will be apparent to one of ordinary skill in the art, and will also be apparent in several ways to a wide range of attentive readers. Some embodiments address technical activities that are rooted in computing technology, such as providing an interface to more easily correlate devices and the controllers that they will be wired to. This allows easy changes to controllers during the construction process, as equipment is often moved around, controllers are moved, etc., without requiring days or weeks of effort to recreate the controller I/O wiring. Buildings can also be constructed more efficiently as benefits that are not apparent until the construction process can be implemented with little down-time, as wiring diagrams and point mapping diagrams can easily be recreated. Further, as a building or other physical space can build its controller wiring diagram completely within a single controller (or multiple controllers networked only to each other) the entire system has a level of security unable to be reached with systems that are connected to the greater internet. In a multiple controller system, the different controllers may be self-federating, such that they can choose a master controller, can choose a different master controller if the original master has problems, can chunk computer programs to run on multiple controllers, etc. Other advantages based on the technical characteristics of the teachings will also be apparent to one of skill from the description provided.

I. Overview

In some embodiments, a user inputs a defined space layout into a controller system. This layout may be input in a variety of ways, without limitation, by inputting blueprints, by scanning an existing defined space using a 3-d scanning device, by using an interface associated with the controller system to input the defined space layout, etc. Some of the file types that may be used are GBXML, IFC, RESCheck, ComCheck, etc. In some implementations, once a defined space is input, equipment and sensors (devices) are placed within the defined space representation within the control system. The devices are not just an icon, as far as the system is concerned, they, rather, are a piece of equipment that changes one or more types of state (e.g., temperature, humidity, sound, air quality, etc.) at a known rate, and uses energy at a known rate, is attached to other devices, which affects them, and so forth.

The defined space itself is not just a series of lines. Rather, walls are understood as devices that diffuse state through at a given rate; doors and windows have different rates; different walls with different compositions all may have different state movement rates; air in a room percolates state. rooms affect each other, and so forth. In some system, weather can be input and affects the building. Once some portion of this information is known, then the system can design. The system determines where the controllers are, and develops a point map showing how the wires in the sensors, equipment, and other devices will connect to the controllers. In some embodiments, the system also provides a guided wiring diagram for the electrical wiring in the defined space, such that the diagram can be used to wire the sensors, equipment, and other devices.

Once the wiring diagram has been created, a user can change the location of one or more devices within the controller, and the system will automatically generate a new wiring diagram and make other changes that go along with the new wiring diagram. The system also gives (near) universal protocol translation, in that different protocols are understood and, in some instances, translated into a common protocol used by a controller that can re-translate back to the protocol understood by a given device. In some embodiments, the system determines how many of each kind of I/O module is needed to fill in the controller topology—for example, a controller may have room for eight modules, while a satellite controller may have room for a different number of modules. In some implementations, satellite controllers may hold two modules.

In some embodiments, to determine how many of each kind of I/O module is needed to fill in the controller topology the controller system determines how many pins and of what type the different I/O the different module types have. The controller understands what are the requirements to wire the devices to either it or a different controller on the same system. The controller also understands what the controller device interface is, and which parts of which controllers will accept different devices. If there are devices that cannot be wired appropriately because of the current controller device interfaces, in some systems, the controllers can modify their device interfaces to meet the needs of the devices. In some implementations, the controllers further comprise modules which hold the device interfaces. These module pins (which are a part of the device interface) are then mapped to the device wires. In other implementations, the devices are checked to determine what their wiring needs are; these specific wiring needs are matched to modules. In some embodiments, the controller does not have modules; the devices are mapped directly to the controllers.

In some implementations, locations of the devices within a physical space and their wiring requirements are already known through the model input into the controller. So, wiring paths between a specific device and a location that a controller or a satellite controller is in can be determined; details of how it is to be wired to the controller are also known.

In some implementations, once a device is assigned to one or more controller terminals, the controller can modify its controller terminal to match the type of terminal required by the device.

Once the wiring diagram is created, it is not set in stone. Because the system understands what and where each device is, and exactly how it is wired, changes can easily be made on the user interface, which will then generate a new wiring diagram, changing the parts that have been modified. For example, if a problem arises during construction that requires placing a piece of equipment in a new location, that change can be made to the digital twin the computer representation using a controller interface. The system will then generate the new wiring diagram, including the new pin diagram if the piece of equipment needs to be moved to a different controller.

As the controllers understand the nature of the objects/devices/equipment that are wired to them, they know what the inputs and outputs for each terminal should be. Each terminal (in some embodiments) have a built in multimeter to ensure the wires are installed correctly in real time. During the controller's self-commissioning sequence, in some embodiments, modules in the controller, the terminals themselves, and/or the controller (satellite controller etc.) test wires for short circuits, cut wires, and proper sensor and equipment connection. In other systems, only some wires are checked.

II. Exemplary Point Map Interface Systems

With reference to FIG. 1, a system 100 is shown that may be used, in whole, or in part, in any of the embodiments disclosed herein. A controller 105 is disclosed, which may be part of a defined space control system that controls aspects of a space. The space may be a building, a portion of a building, a zone within a building, a room in a building, a floor of a building, a collection of buildings, a collection of buildings and the grounds around them, a portion of a number of buildings, and so forth. The controller may comprise a single controller housed in a single controller box, may be multiple controllers that work together, such as, for example, using distributed systems methods, and so on. These controllers may be capable of mastering the system for the physical space being modeled. At startup, the controllers may vote to elect a leader. If the internal network is damaged, a new leader may be elected, providing I.T. and built-in redundancy. Some controllers may be satellite controllers that comprise a limited set of functions of a controller 105.

In some embodiments, the controller 105 comprises a processor 115, and a memory 120. This processor 115 and memory 120 may house and run computer programs 190 that may be used in the embodiments disclosed herein. The controller may further comprise on-board networking hardware 165 and software such as bluetooth. The network components 165 may also comprise hardwired network (e.g. Ethernet), a wireless network, or both.

The controller may also comprise a user interface 170 that allows users to enter information into the controller, and allows the controller to output information. The user interface may be a screen with a keyboard, a printer, a touch screen, a motion sensor, a 3-D input device that can be used to scan a space, such as a room; data may be input using a mouse, a voice-based command system, a touchscreen, a joystick controller, a pointing stick, a trackball, a wii remote, a digital camera, a digital camera with scanning software and/or hardware, a 3-d scanner, a barcode reader, etc. Printers, email, screen views, etc. may be used to output data. A user 185 may interact with the controller 105 through a user interface 170.

Memory 120 in the controller may have stored within it controller information such as a number of predefined device models 125, 140. These may be models of a device that may be wired to the controller through a device interface 155, or able to attach to the controller through a network connection using network components 165. Devices that may be wired to a controller and thus included in a predefined device model include sensors, lighting, ventilation systems, devices used in HVAC systems, such as furnaces, boilers, air conditioners, fans, water heaters and the like; security features such as locks, sirens and the like; entertainment features such as sound systems and audio-visual systems; irrigation systems, such as watering systems, etc. The predefined device models 125, 140 may be models of such devices.

In some embodiments, the predefined device models 125, 140 comprise device names 135, 150. Some devices represented by predefined device models may have more than one wire to attach to a controller. In such a case, in some embodiments, each wire has a device terminal attribute 130, 145 and a name 135, 150. This makes each wire be able to have its own device terminal attribute and a name that allows the wire to be identifiable. The predefined device models 125, 140 may further comprise device terminal interface attributes 130, 145. Device terminal interface attributes may be specific attributes that are needed by the controller device interface 155 to be properly attached to the device 175 represented by the predefined device model 125, 140. A device will have a specific protocol, such as the signaling system they expect from the controller, the current and voltage that they use and report back, error messages, etc. One or more of these protocols can comprise the device terminal interface attribute 145.

The controller 105 may also have a device interface 155 which allows the controller to communicate with and/or control devices. For example, the controller 105 may be interfaced to a device (such as, e.g., an air conditioner) through wiring terminals that physically wire the device to the controller. The controller may be able to turn the device (e.g., air conditioner) on and off, if applicable, turn the device to an intermediate setting, run tests on the device, etc.

The device interface has one or more specific values associated with it (device interface value 160) that allow it to interface with devices. For example, some devices use analog signals, some devices use digital signals. Different devices use different sized power supplies. For example, some devices expect a 24 cold DC output voltage, where others use a 12 Volt DC output voltage. Some use a 20 Amp output current, others use a 10 Amp output current, etc. The controller 105, in some embodiments, may also be able to detect errors, and/or read errors that the device is indicating. The controller 105 may be connected to a device, e.g., a sensor, through a wireless network interface that allows the controller to read information from the device, control the device, etc. Some devices may be connected to the controller 105 through both wired and wireless methods. A device 175 has particular requirements to be attached to a device interface. In some embodiments, the particular requirements for the device 175 to be appropriately wired to the device interface 155 are stored in the associated device terminal interface attribute 130. The device interface, where the device 175 will be wired has its own properties, the device interface value 160, that holds the specific attributes of the device interface. For a device to be successfully wired to a controller, the device terminal interface attribute 130, 145 and the device interface value 160 should be compatible.

The computing environment may have additional features. For example, the computing environment may include storage, one or more input devices, one or more output devices, one or more network components 165, such as network interface card, a wireless transceiver, a modem, a router, a wireless access point, etc. Other communication connections may also be included. An interconnection mechanism such as a bus, controller, or network interconnects the components of the computing environment. Typically, operating system software provides an operating environment for other software executing in the computing environment, and coordinates activities of the components of the computing environment. The storage may be removable or non-removable. In some embodiments the computing environment is networked together with no requirement for an outside network connection. The controller may also have network components 165 that comprise wired interface, a wireless interface, or both. This network connection may be entirely within the physical space that the controller resides in, such that the controller (or controllers that work together as a distributed system) make up an edge computing system with low latency.

The controller 105 also includes one or more computer-readable storage media 180. Media 180 may be of different physical types. The media 180 may be volatile memory, non-volatile memory, fixed in place media, removable media, magnetic media, optical media, solid-state media, and/or of other types of physical durable storage media (as opposed to merely a propagated signal). In particular, a configured medium 180 such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile memory medium may become functionally a technological part of the computer system when inserted or otherwise installed, making its content accessible for interaction with and use by central processing unit 115 within computer hardware included within the controller. The removable configured medium 180 is an example of a computer-readable storage medium 180. Some other examples of computer-readable storage media 180 include built-in RAM, ROM, hard disks, and other memory storage devices which are not readily removable by users. Neither a computer-readable medium, nor a computer-readable storage medium nor a computer-readable memory is a signal per se.

FIG. 2 describes the device interface 155, 205, used in some implementations, in more detail. In some embodiments, a device interface 155, 205 may comprise a controller 200 attached through a controller connector 210 to a module 215. The module may have a Device Connector 220 which is attached to a device 225 through a device wire 230. The controller device interface 205 is therefore connected to the device 225 through the module 215. Either the Controller Connector 210 or the Device Connector 220 may be a terminal connector. The terminal connector (e.g., the Controller Connector 210 and/or the Device Connector 220) can be any sort of wiring terminal that attaches a device or an intermediary (such as a module) to a controller, as known to those of skill in the art. For example, and without limitation, a device may be physically wired to a wiring terminal, connected by cable connectors (e.g., twisted-pair connectors, coaxial cable connectors, or fiber-optic connectors), USB connectors, pin connectors, and so on.

The device may correspond to any device that may be wired to the controller 200 and/or module 215, such as a piece of HVAC equipment, a sensor, a security device, a sound/entertainment system, a piece of equipment in irrigation system such as a pump, etc.

FIG. 3 at 300 shows some of the aspects of a module 305, with emphasis on the circuit board 315 and the wiring connection portions. In some embodiments, the module 305 itself can make decisions and do processing using hardware 320 and memory 325 on its circuit board 315. In some embodiments, when a device will be connected to the controller 335 through a module 305, the device interface value 160, 345 may be kept in the memory 325 of the module 305. The memory may comprise software programs that can be run using the hardware 320. A controller 335, though a controller connector 350 may send messages to a module connector 310. The module connector 310 may then send those messages to its circuit board 315, which may then process the messages and make decisions. This may result in an altered signal from the signal originally sent by the controller 335. This altered signal may then be passed to a Device Connector 330 which sends it to a device 340.

This process may work the opposite way as well. A device 340 sends a message through a Device Connecter 330 to the circuit board 315, which may then process the message, changing the signal. The changed signal is then sent through the module connector 310 to the controller 335. In some embodiments, the signal is not changed from the controller 335 to the device 340. In some embodiments, the signal is not changed from the device 340 to the controller 335. In some embodiments, the circuit board 315 can change the nature of the device connecter 330 that is connecting to device 340 depending on the device 340's requirements.

In some embodiments, the Device Connector may have built-in line testing that ensures that the wire is connected properly to the controller. The device connector, in some embodiments, has zero or more of: built in voltage, current, power monitoring, or fault detection. In some embodiments, the Device Connector has a multimeter to ensure the wires are installed correctly in real time. In some implementations, the circuit board 315 of the module 305 may be able to test wires for short circuits, cut wires, and/or proper sensor and equipment connection.

III. Exemplary Point Map Interface Methods

FIG. 4 illustrates a flowchart 400 to generate a point mapping interface. The operations of flowchart 400 presented below are intended to be illustrative. Technical methods shown in the Figures or otherwise disclosed will be performed automatically, e.g., by a computer program in memory 120 run on a processor 115. A human user may launch a program stored in memory 120 to generate a point mapping interface, leading to a mix of manual and automatic actions, although no entirely manual methods are contemplated herein. Users may Instigate other steps as well. Steps in an embodiment may also be done in a different order than the top-to-bottom order that is laid out in FIG. 4. Zero or more illustrated steps of a method may be repeated, maybe with different building plans, device instances, locations, and so forth. Steps may be performed serially, in a partially overlapping manner, or fully in parallel. In particular, the order in which the flowchart 400 is traversed to indicate the steps performed during a method may vary from one performance of the method to another performance of the method. The flowchart traversal order may also vary from one method embodiment to another method embodiment. Steps may be omitted, and/or repeated. Steps may also be be performed on one or more controllers that use a distributed operating system to communicate, or otherwise depart from the illustrated flow, provided that the method performed is operable and conforms to at least one claim.

In some embodiments, flowchart 400 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of flowchart 400 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of flowchart 400.

At operation 405, at least a portion of the physical structure representation 110 is displayed on a user interface 170. The controller 105 may accept the physical structure representation into programmable memory using any method known to those of skill in the art; it may be sent over an ethernet connection, a wireless connection, and so on. The physical structure representation may be of any type known to those of skill in the art. In some embodiments, the physical structure representation is built using a 3-D scanner, and then imported into the controller; in some embodiments blueprints in computer-readable format are imported in, some combination of the above; in some embodiments, the controller 105 is used to enter the physical structure representation, and so on.

FIG. 5 depicts an exemplary user interface screenshot 500 that can be used to display a physical structure representation 505 and to interact with a list of predefined device models. The illustrative physical structure representation 505 embodiment comprises three zones. Representations displayed may include some combination of walls, floors, doors, windows, irrigation piping and other building or other structure features. Different portions of a larger physical representation, such as a building, or a smaller representation (such as the entry of Zone 3) can be chosen in the panel 530.

At operation 410, a list of predefined device models are displayed on a user interface. A list of predefined device models 525 (e.g., sensors) can be seen in a left-hand panel of the screenshot. Other groupings of predefined device models can be chosen by selecting drawers 535. Other methods of displaying predefined device models are also envisioned. At operation 415, the controller accepts a device model 510 from the list of predefined device models 525. Once a user has selected a device model 510, the controller can acknowledge such selection by accepting the device model as the one that is to be wired, etc. Once a user has selected a device model, e.g., 510, the user can then drag or otherwise place it in a specific location 515 within a physical structure representation 505.

At operation 420, the controller accepts placement of the device model into a location 515 in the physical structure representation 505. Once a user has moved a device model 510 into place, the controller can determine where in the physical structure representation the device model is. This includes understanding where the device model is with reference to walls 540 and other physical features. In some embodiments, a user may input a new device model using software and I/O associated with the controller, such as with an interface 520, which allows a user to input, e.g., a manufacturer, a model, and other information which may comprise specific information about how the unit model behaves. After inputting the new unit model, the unit model may then be added to the list of predefined models 525.

At operation 425, the controller accepts mapping of the device terminal interface attribute to the device connector. A device has a specific requirement for each wire that will be wired to a controller. FIG. 6 illustrates a relationship between a device terminal interface attribute and a device connector 600. A predefined device model 125 has a device terminal interface attribute 130, 605 associated with it. This device terminal interface attribute 605 defines the feature or features that a device connector 610 should have to successfully be wired to the eventual device. The device connector 610 may be directly attached to a controller or may be attached to a module which itself attaches to a controller. For a controller to map a device terminal attribute to a specific device connector 330, 610 on a controller 105 (or on a controller through a module) the controller should know what controller terminal connection will be mapped to a given wire of a given device.

FIG. 7 illustrates a screenshot 700 which represents a mapping between a device and a controller within a representation of the controller. This may be called point mapping diagram creation. The controller may be able to determine what the device terminal attribute is, and which terminal connection on the controller will accommodate the device by utilizing this or a similar screen mapping. In this illustrative embodiment, a controller 105 has six modules 305, labeled 1-6 connecting to the controller 105. The module label 3 is shown at 720. This module is currently holding three devices 715. The module 730 has six empty terminals, each which can hold a single device connector. The label 725 points to a single empty terminal in module 6. Two module slots are empty, as shown at 705. In some embodiments, there is an indication of a module being present. Here, the indication is a number associated with the module input 720. No such number exists in the module input 705, indicating that there is no module attached to the locations indicated by 705.

In this embodiment, individual devices 710 attached to the controller representation are represented on the screen 700, with their names (for the instant example “Swarm”), the area they are in, e.g., “mechanical system zone,” their protocol, e.g., “1-wire+,” the Device Connector types needed, e.g., (−), (1w), (+), and what specific controller device connectors the device will be wired to, in this case module 1, the fourth, fifth, and sixth device connectors 330 from the left. Module location 3 720 has three device representations 715, from left to right, a humidity sensor, a VOC sensor, and a water sensor. Each of these has one or more module attributes 345. For example, each of these are 0-10 v, and have two device connectors that are to be connected to device wires, one a (−), and one a (+).

A user may be able to enter the locations of the devices on the controller location screen 700, the controller may automatically place the devices on the screen, or a combination of the two techniques may be used. Placing the devices on the screen creates the expectation that the same devices will be wired to the controller. Knowing what device is connected, where the device is connected, and what the device terminal attributes of the given device are allows a controller to accept mapping of the device terminal interface attribute to the device connecter.

At operation 430, the controller uses the computer hardware and programmable memory to create a control system topology comprising a point mapping diagram of the controller and the device model within the representation of the physical structure.

In some implementations, users place the controllers within a physical structure representation. In some implementation, controllers are placed automatically within the physical representation. FIG. 8 depicts a screenshot 800 that allows a user to place controllers and/or allow a controller computer system to place controllers automatically. Screenshot 800 may include a physical representation depiction 805 of a portion of a physical space that a controller 105 will be controlling. A manual controller layout selection item 810 may be included which allows users to select one or more different controllers 815 and place them 825 within the physical space representation depiction 805. An automatic layout selection 820 may also be included. This may bring up a controller constraint selection window.

FIG. 9 depicts one layout 900 for a controller constraint selection window. A controller constraint is a rule that determines some aspects about how controllers will be placed within a physical space. Common constraints are a cost restraint equipment cost vs. labor cost, and fill rate constraint controller fill rate vs. controller cost, and so on. Two constraints are shown, “Cost Scenario” 905 and “Fill Rate” 910. In an exemplary embodiment, the cost scenario slider 905 goes from high labor costs (indicated by the icon of a human rolling a large ball 915) to high equipment costs (indicated by the icon of a power switch 920). A user can accept a constraint by setting the slider to a value between high labor cost and high equipment cost. When higher labor cost is chosen, the number of controllers is minimized, as fewer controllers will be used, but the devices will be further from their controller. This increases the average length from the controller to any given piece of equipment is, requiring more labor to install.

In some embodiments, fill rate indicates how full each of the controllers should be, which may be listed in percentages, (0, 20, 40, . . . 100) as shown at 910, though other methods are envisioned, as well. A high fill rate saves money on controllers, but most likely raises installation costs, as, on average, the controllers will be further from the devices they will be wired to. When a low controller fill rate is chosen, such as 40%, it also provides more room for future unit models to be added to the controller, thus minimizing new controller installation costs.

Placement of the controller(s) within the defined space representation is calculated, based partly on the constraint (which may be stored in memory 120). Placement of the controllers also comprises placing devices within specific device connectors within the controller. When many controllers are incorporated, the constraint may make a significant difference in which devices are placed in which controllers. Once the devices are placed, as the device terminal interface attributes 130 are associated with the devices, the controller then knows what the requirements are for the devices, and can therefore create a control system topology whose wiring requirements will be associated with terminals in the controller. The controller will know the number of wiring terminals required by each unit model and the correct type of information for the wiring terminal, and so can create a point mapping diagram of the controller and the device model.

FIG. 10 depicts a controller-module-device hierarchical view 1000. This embodiment shows the hierarchy of the the controller, 1005, the individual modules 1010, and the devices 1015. This hierarchy is generated by the controller 1005 to be used to wire the devices 1015 to modules 1010, and shows which modules 1010 are to be (or are) plugged into the controller 1005. In some embodiments, a user selecting the controller 1005 will bring up a more detailed controller picture, such as that shown in FIG. 7. Similarly, in some embodiments, selecting a module 1010 displayed on the user interface will display the details of the module; and in some embodiments, selecting the device 1015 will display more information about that specific device. For example, if the controller and the devices have been installed correctly, selecting a device may show the current device value(s). For example, a temperature sensor may display the current temperature it is reading. If the controller has yet to be set up, then selecting the device icon may bring up the device within the module and controller that it is to be installed in.

FIG. 11 depicts a controller-module-device hierarchical view 1100 with multiple controllers, in this exemplary case, four. In some embodiments, there are multiple controllers, and the user can place devices within a controller system. In an embodiment, a request can be made that a device be moved from one controller to another. This may be done, by a user selecting a device 1105 and then using the user interface to move the displayed device to an open location 1110 on another location. For example, a user may select the device and then move the device to an open module location on a different controller. Moving the device, and then selecting a rebuild (or a build) within the interface will rebuild the control system topology.

FIGS. 12-20 depict more point mapping diagram creation and modifications within a representation of the controller. FIG. 12 depicts a controller I/O setup screenshot 1200 that allows device placement, e.g., a user can move a device within a controller. A predefined device model 905—a three way valve, in this instance—with three device terminal connection types (also called ‘point types’) (−), (O), and (C) from left to right, can be seen being moved to three wiring terminal locations (point locations) 1210. A device 1205, is moved (e.g., by a user 185 using a user interface 170) into the point locations shown at 1210, the device type covering those three locations 1210, when placed. The controller, knowing the terminal locations of the device 1205 type wires, and their device point type (in this case (−), (O), and (C)) can modify the terminal locations represented by the point locations 1210 to match those expected by the device (in this case, a three-way valve) that the device type represents. Moving the device representation from its initial location on module 7 to its new location 1210 on module 2 has the effect that the controller accepts change of the device interface value associated with the module, the change might comprise operationally registering a selection from a predefined list of device terminal interface attributes stored in the programmable memory, as the controller understands the various attributes associated with the device. This allows the controller to recreate the control system topology using the new locations of the devices. Other methods, such as other database storage methods, may also be used.

FIG. 13 depicts a controller I/O setup screenshot 1300 with the three-way valve 1205, 1305 moved into a new location 1315. When the device is moved, the information known about the device, such as the device terminal interface attribute 130, 145, device name 135, 150, etc, moves with it. In some embodiments, a user can move around the individual device pins. Here the device wires from left to right are (C), (−), and (O) 1315. Another three-way valve 1310 is available in the left-hand panel to be moved into the controller representation. In some embodiments, this indicates that the physical structure represented within the controller as a physical structure representation 110 has another device (e.g., a three-way valve) that still needs to be placed.

FIG. 14 depicts a portion of a controller I/O setup screenshot 1400 that illustrates changing a device point type. In some embodiments, a user 185 can select a device point type 1405 on a device (in the instant example, a Three Way Valve 1420) on at user interface 170 integrated into a controller 105. This selection may bring up a list of possible device point types available at that Device Connector location 1410. These device point types 1405 may be associated with a Device Connector 330 associated with a module 305, as explained elsewhere. A user can then select the desired device point type from the list. In this case, the device point type is being changed from a (O) to a (+) 1405. In some embodiments, the user can add options to the list of possible device point types.

FIG. 15 depicts a portion of a controller I/O setup screenshot 1500 that shows a device with its device protocols displayed. A user can change device protocols. Common protocols can be accessed using an interface. In an exemplary implementation, without limitation, a protocol can be changed by selecting a device protocol text location 1415, 1505. A number of supported protocols for that device type are then revealed 1510. A user can then select the desired protocol. The controller 105 will then expect to be connected to a device with the selected protocol along the device connectors 1520 that the device is plugged into. In some instances, this triggers the Device Connector wiring terminal (e.g., the physical wiring terminal) associated with the chosen slot on the controller to modify itself to match the protocol selected by the user. This change may be triggered by a point type modification request from the controller.

In some embodiments, this allows the controller, among other things, to determine during installation if the correct device wire has been connected to the correct controller connector 350, or the correct module 305 Device Connector 330, as the controller understands the protocol that the specific wire should follow, e.g., the voltage expected, the error signals, etc.

If, when the user is changing device protocols, the user chooses a new device protocol that has a different number of device point type wiring locations (device connectors) than the original device model, the display will reflect the new device protocol, including the number of Device Connector wiring locations that are to be wired into the connector. FIG. 16 depicts a portion of a controller I/O setup screenshot that shows the three-way valve device 1505 that has had its protocol changed from 24 VAC (3-WIRE) 1505 to DryContact 1605. The device picture and the Device Connector wiring terminal point types shown on the display have modified what the controller wiring terminals 1610 associated with the display expect. At 1420, a three-way valve is shown with protocol 24 VAC(3 wire) with three point type locations representing three wiring terminals of types (−), (C), and (O). A user may change the three-way valve protocol to DryContact by selecting the protocol option section 1505 of the device display and then clicking on “DryContact” 1510.

FIG. 16 depicts a portion of a controller screenshot 1600 that displays the three-way valve after DryContact has been chosen. As can be seen by the screenshot 1600, two device connectors 330, 1610 are connected to the DryContact Device, rather than the three device connectors 1520 shown on the 24 VAC (3-wire) device 1505 depicted in FIG. 15. The three-way valve 1505 with three terminal connections (−), (O), and (C) 1515 has now turned into a DryContact three-way valve with two terminal connections (B), (A) 1615, and a gap 1620 with no device terminal connection.

FIG. 17 depicts the result 1700 of moving a device model on a controller I/O setup screen. In this exemplary case, the Dry Contact Three Way Valve 1605 is moved (e.g., by a user 185 using a user interface 170, or a different method) one Device Connector 330 to the left, leaving the far right Device Connector 1705 empty.

As another example, FIGS. 18, 19, and 20 depict screenshots 1800, 1900, 2000 that show controller I/O setup interface embodiments allowing a device to be selected that has been already placed within the controller representation, and then changed to a different protocol. In this illustrative example, the device selected is a temperature sensor 1805 with a 0-10V protocol. A user selecting the device can display a menu of protocols 1905 that can be used with the temperature device 1805, here “RTD”, “Thermistor”, “0-10V”, and “2-10V”. The current device has the device point types (−) and (+) 1910, reading from left to right. As shown at 2005, the user selected the protocol RTD, which changes the device type template (and thus, the protocol) to RTD 2005 which also changes the device connectors 330 from (−), (+) 1910 to (+), (−) 2010.

In some embodiments, when a controller automatically places devices within its I/O panel/screen and/or when a user changes locations of devices, the individual device connectors may be required to change types to match the requirements of their new devices. For example, with reference to FIG. 15 and FIG. 16, a Three Way Valve is changed from 24 VAC (3-wire) protocol 1505 to a DryContact Protocol 1605. This changes the protocol of its device connectors from (−), (0), (C) 1515 to blank, (B), (A), 1615. The physical device terminals associated with the new Dry contact protocol therefore need to change from accepting an (0) to a (B) and a (C) to an (A) In some implementations, the controller or the module can modify its device connectors to accommodate the new protocols expected at changed locations, e.g. those represented by locations 1610. This controller or module, knowing what sort of device connectors are needed, can modify its device connectors to be of the correct type.

FIG. 21 depicts a block diagram 2100 of a module 2102 that can modify its device connectors to accommodate different sorts of device wires with their different requirements. The module 2102 does processing and makes decisions using hardware and memory 2110 on its circuit board 2105. For example, a controller can send a signal 2175 to a module telling it to change the type of a Device Connector A 2130 attached to the module 2102. The module 2102 sends the message to its circuit board 2105 which may be able to determine which of its device connectors 2130, 2150, 2170 are associated with the device. In some embodiments, the module 2102 may be sent the information about which Device Connector 330 the message will be sent to from the controller 105. The module 2102 may then pass the information on to Device A 2180. The same module may be able to handle both situations: the module determines the correct Device Connector 330 in some instances and the controller 105 determines the correct Device Connector 330 in some instances.

In some embodiments, a module 2102 has three Device Connectors, Device Connector A 2130, Device Connector B 2150, and Device Connector C 2170. Device Connector A 2130 is connected by a device wire 2195 to Device A 2180. Device Connector B 2150 is connected to Device B 2185 by device wire 2197. Device C 2170 is connected by device wire 2179 to Device Connecter C 2190.

In some exemplary embodiments, Device connector C 2170, in this instance, may be able to provide six different functions, eg., types 1 through 6. The circuit board has hardware, e.g., chips, associated with the Device Connectors A 2130, B 2150, and C 2170 that can be enabled by the module receiving the appropriate signal from the associated controller, enabling the device connectors 2130, 2150, 2170 to be of any (or, in some embodiments, all) of those types. Device Connector A 2130 has, associated with it, hardware for three types: Type 1 2115, Type 2 2120, and Type 3 2125. Device Connector 2, similarly has the hardware potential to be of three types as well—Type 1 2135, Type 2 2140, and type 3 2145. Device Connector 3 has different types associated with it: Type 4 2155, Type 5 2160, and type 6 2165.

In some embodiments, the controller sends a signal 2175 (or a program or another indication) to the module 2102 that Device Connector A 2130 is expected to be type 1 so that it can correctly interface with device wire 2195 associated with device A 2180. The module 2102 may then be able to use a processor that is part of its hardware and memory 2110 on its circuit board 2105 to send a signal 2199 telling a Device Connector A 2130 to be of Type 3 2125. The module 2102 may be able to connect wire connector 1 type 3 2125 to Device Connector A 2130, making Device Connector A 2130 of type 3 2125. In some embodiments a single Device Connector may be multiple Device Connector types; for example, Device Connector A 2130 could be both type 2 2120 and type 3 2125.

In some embodiments, at least one of the types 1 through 6 are enabled by chips, and modifying the Device Connector comprises the hardware/memory 2110 sending signals through wires 2180 to activate a chip to add function(s) and/or deactivate a chip to subtract function(s).

FIG. 22 at 2200 is an extension of Device Connector A shown in the module 2102 of FIG. 21. In some embodiments, a module has a series of potential circuits that can be enabled. In this exemplary embodiment, the example module circuit board has at least one of a voltage monitoring circuit 2205, a current monitoring circuit 2210, a power monitoring circuit 2215, or a fault detection circuit 2220 controlled by at least a portion of its hardware/memory 2110. In some embodiments, a user may be able to specify these requirements using a device interface 155 associated with the controller 105. These circuits can be used to monitor the voltage, current, and/or power of a device wire 2195 associated with device A 2180, and either connected to Device Connector A 2130 or to be connected to Device Connector A 2130. This may check that the correct wire e.g., 2195 of the correct device e.g., 2180 has been attached to the controller 105 through a module 2102. This may check that the device 2180 is behaving correctly, in that it is sending the correct signals along device wire 2195. The controller may be able to determine which values are received from the device wire 2195 and check to see if they are the expected values. As the controller understands what device A 2180 is, and what its protocol is, the controller checks what values are coming from the device wire 2195 against expected values.

In some embodiments, a device connecter may have a series of circuits that are enabled. A message 2180 from a controller to which a module 2102 is connected may be used to turn off one or more of the chips interacting with a Device Connector (e.g., Device Connector A 2130).

The monitoring values (e.g., voltage, current, power) can be displayed on a device interface 155 associated with a controller 105, that is associated with the module 2102 that is itself associated with the circuit board 2105. In the described embodiment, Device Connector A has available terminal types 1-6 2220, 2225, 2230, 2235, 2240, 2245.

In some implementations, devices are wired to the module, creating a wired device. Modules may test device wires, e.g., 2195 from the wired device e.g., 2180 for various faults, such as short circuits, and/or cut wires, etc. In some implementations, the module may use hardware/memory 2110 on its circuit board 2105 to perform these tests. In some implementations, the module may pass signals to its controller 105 to perform these tests.

In some embodiments, a controller 105 associated with the module 2102 runs computer programs that allow the device connections to be defined. The controller then sends instructions to the module telling it which Device Connector (device wire pin) is expected to have which features or requirements. In some embodiments, the device connectors on a module may be defined to be any of a series of functions, these functions being device connection types. These functions comprise, without limit: thermistor, RTD, 1-Wire, 0-10 V Input/Output, 0-20 mA Input/Output, 0-480 VAC Input, 24 VAC Output, or Modbus/RS485 Interface, power control blocks, SPDT relays (10A), up to 240 VDC/VAC, real-time current monitoring, real-time voltage monitoring, overcurrent protection, 120/240 VAC output—2 Amps, or 24 VAC output-2 Amp, 12/24 VDC motor drivers, PWM speed control, real-time current monitoring, real-time voltage monitoring, overcurrent protection, torque protection, and tachometer feedback. Other options are also available.

In view of the many possible embodiments to which the principles of the disclosed invention may be applied, it should be recognized that the illustrated embodiments are only examples of the invention and should not be taken as limiting the scope of the invention. Rather, the scope of the invention is defined by the following claims. We therefore claim as our invention all that comes within the scope and spirit of these claims.

Claims

1. A method for creating a control system topology comprising:

a controller having a device interface, computer hardware, programmable memory, a user interface, a physical structure representation in programmable memory, and a list of predefined device models in programmable memory, the predefined device models having corresponding device terminal interface attributes, and device names;

displaying the list of predefined device models on the user interface;

displaying at least a portion of the physical structure representation on the user interface;

the controller accepting a device model from the list of predefined device models displayed on the user interface;

the controller accepting placement of the device model into a location in the physical structure representation;

the controller accepting mapping a device terminal interface attribute associated with the device module to the device interface; and

the controller using the computer hardware and programmable memory to create a control system topology comprising a point mapping diagram of the controller and the device model.

2. The method of claim 1 wherein the device interface further comprises a device interface value and further comprising when the device interface value and the device terminal interface attribute do not match, the controller uses a program stored in programmable memory to change the device interface value to the device terminal interface attribute.

3. The method of claim 1 wherein the controller is operationally able to accept change in device interface value from user input.

4. The method of claim 1 wherein at least a portion of the control system topology is displayed on the user interface.

5. The method of claim 2, wherein a module connects to the controller and wherein the device terminal interface attribute matches the device interface value associated with the module.

6. The method of claim 5, further comprising accepting change of the device interface value associated with the module, the change comprising operationally registering a selection from a predefined list of device terminal interface attributes stored in the programmable memory, and wherein the controller recreates the control system topology using the selection.

7. The method of claim 5, wherein the device interface is wired to a device creating a wired device, and where the controller is operationally able to detect a fault in the wired device.

8. The method of claim 5, wherein the controller accepting mapping the device terminal interface attribute to the device interface further comprises the controller signaling to.

9. The method of claim 1, further comprising at least a second controller and wherein the user interface is configured to allow a user to input a request to move the device model to a different location on the second controller, and wherein the request rebuilds the control system topology.

10. A controller having a device connector, a processor, programmable memory, a user interface, a physical structure representation in programmable memory, a list of predefined device models in programmable memory, predefined device models in the list having corresponding device terminal interface attributes, and a physical structure representation in programmable memory; a program residing in memory, the program allowing input of controller information and modification of controller terminals, including instructions residing in the memory, which are executable by the processor to perform a method which includes:

displaying the list of predefined device models on the user interface;

the controller accepting a device model from the list of predefined device models displayed on the user interface;

the controller accepting placement of the device model into a location in the physical structure representation;

the controller accepting mapping a device terminal interface attribute associated with the device model to the device interface; and

the controller using the processor and programmable memory to create a control system topology comprising a point mapping diagram of the controller and the device model within a representation of the controller.

11. The controller of claim 10, further comprising a second controller and wherein the user interface is configured to allow a user to input a request to move at least one of the predefined device models to the second controller, and wherein the second controller rebuilds the point mapping diagram.

12. The controller of claim 10, further comprising a second device interface, and wherein the controller accepts, from the user interface, device placement on the second device interface.

13. The controller of claim 12, wherein the controller modifies the Device Connector to match requirements of the device model.

14. The controller of claim 10, wherein the controller is operationally connected to a module, the module comprises a device connector, and wherein the module modifies the Device Connector to match requirements of the device model.

15. The controller of claim 14, wherein the module modifies the Device Connector by activating a chip.

16. The controller of claim 14, wherein the module modifies the Device Connector by deactivating a chip.

17. The controller of claim 10, further comprising a controller constraint, and wherein the controller constraint at least partially determines device placement within the controller.

18. The controller of claim 17, further comprising a controller-module-device hierarchy with first controller and a second controller, and wherein a device associated with a first controller can be moved to be associated with the second controller.

19. The controller of claim 17, wherein the controller constraint comprises a labor vs equipment cost constraint or a fill rate constraint.

20. A computer-readable storage medium configured with data and with instructions that upon execution by at least one processor in a controller computing system having a device interface, computer hardware, programmable memory, a user interface, a physical structure representation in programmable memory, and predefined device models in programmable memory, the predefined device models having corresponding device terminal interface attributes, and device names; will cause the at least one processor to perform a technical process for point mapping diagram creation, the technical process comprising:

displaying the list of predefined device models on the user interface;

displaying at least a portion of the physical structure representation on the user interface;

the controller computing system accepting a device model from the list of predefined device models displayed on the user interface;

the controller computing system accepting placement of the device model into a location in the physical structure representation;

the controller computing system accepting mapping the device terminal interface attribute to the device interface; and

the controller computing system using the computer hardware and programmable memory to create a control system topology comprising a point mapping diagram of the controller computing system and the predefined device model.