US20220067227A1

US20220067227A1 - Automated Point Mapping Generation

Info

Publication number: US20220067227A1
Application number: US17/216,565
Authority: US
Inventors: Troy Aaron Harvey; Jeremy David Fillingim
Original assignee: PassiveLogic Inc
Current assignee: PassiveLogic Inc
Priority date: 2020-08-26
Filing date: 2021-03-29
Publication date: 2022-03-03
Also published as: US11553618B2; US20230328912A1; US20220067230A1; US12089360B2; US20240349437A1; US12156360B2; US20240422934A1; US11871505B2; US20250031335A1; US20220418141A1; US20250203801A1; US12324120B2; US20220066754A1; US20220066434A1; US12408287B2; US11477905B2; US20220067261A1; US11596079B2; US12069831B2; US20230180420A1

Abstract

Tools and techniques are described to automate creation of point mapping diagrams between controllers and controlled resources. After receiving a defined space diagram (which may be input using a graphical interface of the controller, or by other means), resource locations and resource wiring requirements (which may be done automatically), a wiring diagram including point mapping between the resources and any necessary controllers is generated. If resources need to be moved, a new wiring diagram and/or point mapping can be regenerated.

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 INVENTION

The present disclosure relates to generating point maps, and more particularly to automatically generating point maps by creating a digital version of resources that are to be point mapped, and a digital version of the space that the resources will be in, which allows near-automatic creation of point maps.

BACKGROUND

Wiring diagrams take hours to create. Further, if a problem comes up when building a structure that requires that a wired device must be moved, the wiring diagram must be recreated from scratch, which can entail quite a bit of 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 wiring diagrams.

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. This summary does not identify required or essential features of the claimed subject matter. The innovation is defined with claims, and to the extent this Summary conflicts with the claims, the claims should prevail.
In general, one innovative embodiment comprises accepting a building representation into a controller, the controller comprising a processor, memory, and a user interface; accepting a unit model from a list of predefined models displayed on the user interface, the unit model having wiring requirements and location within the building representation; accepting a constraint; calculating placement of the controller within the building representation based at least partially on the constraint; determining a wiring route between the controller and the unit model based at least in part on the building representation; and determining point mapping between the controller and the unit model based in part on the wiring requirements.
Some embodiments display the point mapping on the user interface. Some embodiments allow a user to move a unit model to a new location on a digital display, which can rebuild the wiring route or the point mapping.
Some embodiments comprise a wiring module with a terminal wiring requirement. After a wiring diagram has be generated, a user can modify the wiring module; and the controller is able to determine if the modification is legal for the controller. If so, the controller can regenerate a new wiring diagram. Some embodiments allow the controller to modify wiring pins to match device wiring requirements.

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 is a functional block diagram showing an exemplary embodiment of a controller in conjunction which some described embodiments can be implemented.

FIG. 2 is an exemplary block diagram of a resource interface in conjunction with which some described embodiments can be implemented.

FIG. 3 is an exemplary flow chart illustrating steps in some methods of automated point mapping generation with which some described embodiments may be implemented.

FIG. 4 is an exemplary block diagram of a unit model which some described embodiments can be implemented.

FIG. 5 is an exemplary diagram showing how, in some embodiments, location can be determined.

FIG. 6 is an exemplary diagram how, in some embodiments, unit model aspects can be determined.

FIG. 7 is an exemplary diagram showing potential wiring constraints that can be used in some embodiments.

FIG. 8 is a diagram showing relationship between a controller and unit models that can be used in some embodiments.

FIG. 9 is is a diagram of an exemplary controller-unit model wiring relationship in conjunction with which described embodiments can be implemented.

FIG. 10 is an exemplary network controller wiring diagram in conjunction with which described embodiments can be implemented.

FIG. 11 is an exemplary network controller device wiring diagram in conjunction with which described embodiments can be implemented.

FIG. 12 is an exemplary network controller module device wiring diagram in conjunction with which described embodiments can be implemented.

FIG. 13 is an exemplary network wiring diagram with multiple controller types in conjunction with which described embodiments can be implemented.

FIG. 14 is an exemplary point map in conjunction with which described embodiments can be implemented.

FIG. 15 is an exemplary screen shot in conjunction with which described embodiments can be implemented.

FIG. 16 is is a block diagram of an exemplary controller portion in conjunction with which described embodiments can be implemented.

FIG. 17 is is a block diagram of an exemplary controller-module relationship in conjunction with which described embodiments can be implemented.

FIG. 18 is an exemplary portion of a screen shot with which described embodiments can be implemented.

FIG. 19 is an exemplary portion of a screen shot with which described embodiments can be implemented.

FIG. 20 is a block diagram illustrating an automated point mapping system having at least one processor and at least one memory which interact with one another under the control of software, and also illustrating some configured storage medium examples.

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).
Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as being illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” and “in one embodiment.”

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, etc. In some implementations, once a defined space is input, equipment and sensors are placed within the defined space representation within the control system, then the system designs itself. The system determines where the controllers are, and develops a point map showing how the wires in the sensors, equipment, and other resources 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 resources.
Once the wiring diagram has been created, a user can change the location of one or more resources within the controller, and the system will automatically generate a new wiring diagram and make other necessary changes. In some embodiments the system uses the wiring diagram to determine the controller topology and develop a 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 resource. 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 8 modules, while a satellite controller may have room for two modules. This entails determining how many pins and of what type each I/O the different module types have. These are then mapped to the resources. In other implementations, the resources 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 resources are mapped directly to the controllers.
In some implementations, locations of the resources and their wiring requirements are already know through the model input into the controller. So, wiring paths between a specific resource 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.
Constraints can be added to the system that creates the wiring diagram and point mapping. Common constraint inputs are minimizing labor, minimizing hardware, maximizing labor, maximizing hardware, and/or specifying fill rate of hardware.
Some constraints can be thought of as decreasing one possible constraint which, by nature, increases another. Examples include equipment cost vs. labor cost, and controller fill rate vs. controller cost. When higher labor cost is chosen, the number of controllers is minimized. This increases the average length from the controller any given piece of equipment is, requiring more labor to install. Then, it can be determined how to group resources and modules and controllers to make installation (how much wire must be used? How much labor will installation take?) as efficient as possible by doing resource analysis (what are the resources), location analysis (where are the resources), I/O analysis (how many terminals are available, what can the terminals do), and constraint analysis (fewer/more controllers, lower/higher labor cost). Such a controller hierarchy grouping is shown in FIG. 10. Such computer-determined groupings can be viewed on a user interface, such as the one on a controller that this system might have been built on. The user is not required to use the controller created hierarchy, but, in some embodiments, can modify it, either by using the user interface or can modify in a different way.
Once the mapping between the equipment and the controllers is determined, then the system (which might be the computer hardware and software associated with the controller or set of controllers used to design the defined space) can create the point mapping wiring diagram and/or the full defined space wiring diagram.
Once the wiring diagram is created, it is not set in stone. Because the system understands what and where each resource is, and exactly how it is wired, changes can be easily be made on the user interface, which will then generate a new wiring diagram, changing only 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/resources/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.
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 more efficiently generating point mapping diagrams. This, in turn, makes constructing buildings and similar structures much easier, as resources and sensors can be moved during the construction process without requiring days or weeks of effort to recreate a point mapping diagram. 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. Other advantages based on the technical characteristics of the teachings will also be apparent to one of skill from the description provided.

II. Exemplary Method for Automatically Creating Point Maps

With reference to FIG. 1, a system 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. Some controllers may be satellite controllers that comprise a limited set of functions of a controller 105. The controller 105 comprises a processor 110, and a memory 115. This processor and memory may house and run computer programs that may be used in the embodiments disclosed herein.
The controller may also comprise a user interface 120 that allows users to enter information into the controller, and allows the controller to output information. The user interface may be, without limitation, a touchscreen associated with the controller, may be a slidable screen that opens to disclose the controller wiring, may be a screen attached to a computer associated with the controller, etc. The controller may also have a wired interface, a wireless interface, or both. The controller may also have a resource interface 125 which allows the controller to communicate with and/or control resources. This resource interface may be one or more wiring terminals which a resource may directly attach to. Once attached, the controller may be able to communicate with the resource. The controller 105, in some embodiments through its resource interface 125 may also be able to detect errors, and/or read errors that the resource is indicating. For example, an air conditioner may be wired to a controller. The controller can then turn the air conditioner on and off, and, if applicable, turn the air conditioner to an intermediate setting, determine if the air conditioner has ceased to send inputs, is sending incorrect inputs, is sending error messages, etc.
FIG. 2 describes the resource interface 135, 205, used in some implementations, in more detail. In some embodiments, a resource interface 135 may comprise a controller 105 attached through a controller connector 210 to a module 215. The module may have a resource connector 220 which is attached to a resource 225. The controller resource interface 205 is therefore connected to the resource 225 through the module 215. The controller connector 210 and the resource connector can be any sort of wiring terminal that attaches a resource 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 resource may be physically wired to a wiring terminal, there may be connected by cable connectors (e.g., twisted-pair connectors, coaxial cable connectors, or fiber-optic connectors), USB connectors, pin connectors, and so on.
The resource may correspond to a resource that may be wired to the controller, such as a piece of HVAC equipment, a sensor, a security resource, a sound/entertainment system, etc., or any other resource that has the ability to be connected to the controller 105. A resource 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, etc. One or more of these protocols can comprise the resource terminal interface attribute 115.
FIG. 3 illustrates some method embodiments in a flowchart 300. Technical methods shown in the figure or otherwise disclosed may be performed in some embodiments automatically, e.g., by a requiring little or no contemporaneous live user input. In a given embodiment zero or more illustrated steps of a method may be repeated, perhaps with different values, sensors, controllers, or resources to operate on. Steps in an embodiment may also be done in a different order than the top-to-bottom order that is laid out in FIG. 3. In a given embodiment zero or more illustrated steps of a method may be repeated, perhaps with different values, sensors, controllers, or resources to operate on. Steps may be performed in a partially overlapping manner, or fully in parallel, serially. The order in which flowchart 300 is traversed to indicate the steps performed 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 method embodiment. Steps may also be omitted, combined, renamed, regrouped, or otherwise depart from the illustrated flows, provided that the method performed conforms to at least one claim.
At operation 305, a defined space representation is accepted into a controller 105. This defined space representation may be accepted by a user using software stored in memory 115 and the user interface 120; accepting may comprise a variety of methods to input the defined space representation. These may include inputting a blueprint of the space that the controller can read, the space may be scanned using a 3-d scanner; the space may be input using the user interface 120 of the controller 105, a defined space representation may be created using a collection of different methods, and so on, as understood by those of skill in the art.
At operation 310, a unit model is accepted. A unit model is a resource or a sensor or other piece of equipment that can be controlled. Possible unit models, without restriction, are lighting, ventilation, hydronics, such as pumps; heat sources, cooling sources, solar thermal sources, such as solar panels; heat pumps, heat storage, heat exchanges, renewables, VAV components, air components, vents, and sensors. This unit model may be selected from a list of predefined unit models displayed on a user interface on the controller.
With reference to FIG. 4, a unit model 405 may have wiring requirements 410 and a location 415 within a defined space representation. The wiring requirements are the protocols used for its wiring; the number of wires the unit model requires, the specific codes issued by the unit model for various situations, the current and voltage accepted received at various times, etc. In embodiments, the unit model 405 may have a labeled unit attribute 420, which may be a name that the unit model may be stored under (or through the name, a key can be determined that will allow access into a database that holds information about the unit model 405). The labeled unit attribute, in some embodiments, can be displayed on a user interface 120 associated with the controller 105.
With reference to FIG. 5, an exemplary screen display 500 is shown that allows a user to select a predefined unit model resource, in this exemplary instance, a sensor. At 505, a list of predefined sensors are displayed. A user can choose a sensor and then drag or otherwise place it in a specific location 515 within a building representation 510. In another embodiment, a user may input a new unit 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 be added to the list of predefined models. In some implementations, the user may select a user-defined unit model directly.
With reference to FIG. 6, an exemplary screen is shown that allows selection of resource units models, e.g., hydronics, such as pumps; heat sources, cooling sources, solar thermal sources, such as solar panels; heat pumps, heat storage, heat exchanges, renewables, VAV components, and air components. Specifically, in this exemplary implementation, heat sources, e.g., and without limitation, “radiant” (heat), forced air, hybrid, and VAV can be selected at 605. In some implementations, selection involves selecting a resource and then dragging the selected resource into a system pane 615. The selections of specific resources may be included in drawers 610, that when opened up display resource unit models that are already defined. A user can input information about the specific resource, such as a manufacturer at 620. A database associated with the user input system may have information about the manufacturer, in which case, known information may be associated with the resource. In some embodiments, specific information about the unit model (e.g., resource) may be entered at 625. In some embodiments, specific behaviors about the unit model may be entered by the user at, e.g., 630.
Once the selected resource has been moved into a specific location on the user interface representing a location within the defined space, then that location within the defined space representation is considered the presumptive resource location within an actual building. An example of this can be seen in FIG. 5, which shows a sensor placed at a specific location 515 on the first floor of a building representation. In some implementations, the resources have wiring requirements associated with them, and when a resource is selected, then the wiring requirements for the resource are also selected. In some implementations, a user can input wiring requirements for a given resource.
FIG. 7 is an exemplary diagram showing potential wiring constraints that can be used in some embodiments. With continuing reference to FIG. 3, at operation 315, a constraint is accepted. Common constraints are equipment cost vs. labor cost, and controller fill rate vs. controller cost, and so on. In some embodiments, a constraint can be input by a user on a user interface, as shown at 700. In some embodiments, constraints are accepted a different way. Controllers can be wired to some number of unit models (e.g., equipment, resources, sensors, etc.). One of the possible constraints is a cost scenario which allows a user to choose between higher labor costs and higher equipment cost. In an exemplary embodiment, a cost scenario slider shown at 705 goes from high labor costs (indicated by the icon of a human rolling a large ball 715) to high equipment costs (indicated by the icon of a power switch 720). 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 resources will be further from their controller. This increases the average length from the controller any given piece of equipment is, requiring more labor to install.
In some embodiments, another possible constraint is “fill rate”. Fill rate indicates how full each of the controllers should be, which may be listed in percentages, (0, 20, 40, . . . 100) as shown at 710, 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 resources 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.
At operation 320, placement of the controller(s) within the defined space representation is calculated, based partly on the constraint (which may be stored in memory 115). When many controllers are incorporated, the constraint may made a significant difference in placement. At 325, a wiring route is determined between the controller and the unit model 405 based, at least in part, upon the unit model wiring requirements 410. A controller 105 itself, using its processor(s) may create the wiring requirements. In some implementations, multiple controllers working together may create the wiring requirements. In some implementations; the wiring requirements are created using a computer or computers associated with a controller. In some implementations, the wiring requirements are created using a separate computer system. In some implementations the controller 105 understands what the defined space looks like from, e.g., the defined space representation; understands where needed controllers go within the defined space, and understands what the locations 415 of the unit models 405 are. As such, the wiring route can be determined by the controller(s) or other computer implementations using techniques known to those of skill in the art. At operation 330, a point mapping is determined. The point mapping is between the controller (that the unit model will be attached to) and the unit model 405 based in part on the wiring requirements 410, while the actual wiring documentation from controller to unit model is determined by where the controller is placed in relation to the unit model 405.
In an exemplary embodiment, FIG. 8 shows a simple defined space 800 with a controller 805, and three unit models: a boiler 810, an air conditioner 820, and a sensor 815. Placement of the controller 805 is determined based on a number of factors, including the distance between the controller 805, and the unit models. The unit models should have wiring requirements 410 associated with them, either automatically through selection of an associated icon, or through a user entering the information by hand into a user interface, such as those shown in FIGS. 2 and 3.
FIG. 9 discloses an embodiment of controller wiring 900. In some descriptive examples, these 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; e.g., though the methods and systems discussed with reference to FIGS. 5 and 6. The controller, in the example given, will understand the boiler wiring 910 requirements, the location of the boiler 810, the sensor wiring 915 requirements, the locations of the sensor 815, the AC wiling 920 requirements, and the location of the sensor 815. A specific wiring location is shown at 925 where, in this case, a specific air conditioning wire expected to be wired directly into the controller 905.
FIG. 10 at 1000 discloses a first level wiring diagram. Once a defined space representation (e.g., 800) has been set up on the controller and at least one constrain has been determined (e.g., 900), a network wiring diagram can be generated. At its simplest, the wiring diagram describes the number of controllers needed for the defined space, in this example, two, controller 1005 and controller 1010. How the controllers are connected is also shown, here, a single connection 1015 between the two. In some embodiments, clicking on, or otherwise selecting a controller will bring up a point mapping diagram, shown in more detail at FIG. 13. Wiring requirements of the unit models that will be connected to the controller are used to determine how many unit models may be connected to each controller, so how many controllers in total need to be used. The constraints are also used to determine where the controllers will be placed, and how much space is available in each controller. Which unit model is moved into each controller may be determined by location of unit model in relation to controller, etc.
FIG. 11 discloses a network wiring diagram 1100 that shows the controllers 1105, 1110, and also shows the devices 1115 that are (or will be) attached to the controller 1105. Icons 1125 describe what sort of unit model is attached to the controller. In an illustrative example, the user interface is configured to allow a user to input a request to move a unit model, e.g., 1115 from being connected to a terminal wiring location, e.g. on the first controller 1105 to a terminal wiring location, e.g., 1120 on a second controller, e.g, 1110.
FIG. 12 discloses an exemplary network wiring diagram 1200 that shows controllers 1205, modules in the controller 1210, modules in the controller 1210, and unit models 1215 attached to the modules that are attached to the controllers. In some embodiments, unit models can be moved from a location on a module, e.g. 1215, to a location on a same module 1230, a different module 1235, and/or a location on a different controller 1240.
After moving a unit model, a user request can rebuild the wiring route and the point mapping with the new controller-unit model configuration. This may be useful when constructing a building, and when for some reason, a unit model (e.g., a resource) will not fit at its intended location, and must be moved. Moving the unit model using a user interface, such as the one shown at FIGS. 10-13, will allow the wiring diagrams and point maps to be regenerated very rapidly by a controller 105 or a system of controllers that includes controller 105 such that construction can continue unimpeded.
In some embodiments, each of the three views, e.g., those shown in FIGS. 10-13, can be selected by a user. In the displayed embodiment, a thumb 1020 on a slider bar 1025 in the far left position shows the controller only network wiring diagram. The thumb in the middle position 1130 shows the controller-unit model network wiring diagram, and the thumb in the far-right position 1220 shows the controller-module-unit model network wiring diagram. Other methods of display are also envisioned in this disclosure. Controller point maps may also be displayed. In some embodiments, clicking on a controller, e.g., 1005, 1105, 1205, brings up the point map for the given controller.
FIG. 13 discloses network wiring diagram 1300 with multiple types of controllers. A system may comprise two types of controllers: controller leaders 1305, 1310 and satellite controllers 1315, 1330. Control leaders have more hardware and memory than satellite controllers, and, in some systems, send messages to the satellite controllers informing them what messages to give to modules. In some systems, the satellite controller may process the messages to give the unit models. In some systems, the controller leader and the satellite controller may share the tasks. Controllers and satellite controllers may both use modules 1330, 1335 to attach to unit models 1325. Terminal connectors in modules may directly (or indirectly) wire to resources 225 represented by unit modules 1325. A controller may determine an action for a unit model (such as turn on an air conditioner) then either pass that information onto a module associated with the controller itself, or in some embodiments, directly tells a unit model. In some embodiments, the modules 1320, 1335 comprise hardware and software that allows them to make decisions when given information from controllers (e.g., controller leaders and satellite controllers.)
In some embodiments, controller leaders 1305, 1310 are connected 1340, 1345 to other controller leaders and satellite controllers 1315 through wired or wireless methods. These controller leaders may make up a distributed system that shared processing tasks needed to determine tasks, such as generating wiring diagrams and generating pin mapping.
In some embodiments, the controllers are comprised of modules which plug into the controllers. The modules 1030, 1035 may be listed on a display screen 1300. Unit models, e.g., 1325 may be moved to empty locations 1330. After moving a unit model, a user request may rebuild the wiring route and the point mapping with the new controller-unit model configuration. This may be useful when constructing a building, and when for some reason, a unit model (e.g., a resource) will not fit at its intended location, and must be moved.
FIG. 14 discloses a pin mapping screen shot 1400 that can be used to view or modify pin mappings in some embodiments. Once a network diagram has been created, users can change the protocol type of a unit model, can change the pin locations within a unit model, can move unit models to other locations within the controller, etc. For example, a temperature sensor may have been originally spec'd to have an RTD protocol/interface 1405. However, such a temperature sensor may be unavailable, but a temperature sensor with a different protocol, such as “Thermistor” may be available 1420. Selecting RTD 1405 will display a menu or other option that may show the available protocols 1420. Selecting a protocol, such as “Thermistor” will change the protocol expected on this object model, and also change the controller so that it expects the new protocol on the associated wiring terminal(s) 1430. Often, a different protocol will have a different pin wiring format, or because of specific space requirements, etc., or it may be better for a specific installation to change locations of resources (which changes the pin wiring) deep into a construction job. Selecting a unit module 1420 may allow a user to choose another protocol; in this specific example, for this sensor, a user can choose between RTD, Thermisor, 1-10V, and 2-10V. Controller 1400 has six modules 1410, each marked by a number 1435. Two module slots are empty 1415, as shown by no module number 1425 showing. Other modules markings are envisioned by this disclosure.
FIG. 15 discloses a user interface 1500 that allows moving wiring terminals within a unit model. Auser may be able to move pins on a user model by using a user interface representation of the controller. The user can choose a pin representation 1505 and then change it to the desired location. For example, the (O) and the (C) can be swapped. This informs the controller that the pin type is to be the type specified by the user.
In some embodiments, the controller comprises a wiring module with terminal wiring requirements. A user can modify the terminal wiring requirement of the wiring module by selecting a wiring terminal. This may bring up a list of predefined terminal types. The user may then select one of the predefined types.
In some embodiments, when a terminal type is to be changed by, e.g., modifying a screen representation of controller, module, and, or terminal, the terminal is physically changed at the controller or the module or both, depending on implementation. This terminal type can be changed, as, in some embodiments, the terminals are set up with hardware controlled by software that allows them to be switched to various types, by the type being specified by a user, such as, e.g., on a user interface screen such as shown in FIGS. 14 and 15.
The terminal type may be changed at the module level, with hardware and/or software in the module to allow the pin type to be changed. In some embodiments, the modified wiring requirement will be checked to determine that there is a match between the modified wiring requirement and the wiring requirements of the unit model that is connected to the terminal. In some embodiments, the user can change the unit model that is connected to one or more terminals. The modified wiring requirement may be checked to determine if there is a match between the new unit model and the types of terminals that are currently in those locations. If there is not a match, the user may be notified; in some embodiments, the controller may change physical terminal associated with the controller, using a combination of software and hardware. In some embodiments, the resource connector 220 in the module 215 is changed at request of the controller, using the resource interface 205. In some embodiments, the module comprises the hardware that changes the resource connector by receiving a message from a controller.
With reference to FIG. 16, when a terminal type is changed by a user (e.g., using a user interface 120), in some embodiments, the controller 1605 has access to the wiring requirements 410 of the unit model 405, and wiring requirements 1610, 1615 of the controller(s) itself. With reference to FIG. 17, in some embodiments, unit models are, e.g., attached to modules 1720 through their module wiring terminals 1710, 1715. The controller (or controllers) has access to information about the unit models through, e.g., user interfaces such as those shown in, e.g., FIGS. 10-15. Through this knowledge, the controller(s) 1705 can determine whether a unit model currently can be attached to a wiring terminal on a module 1710, 1715 or a controller(s) 1610, 1615. The controller(s) may also be able to determine where a unit model could be attached within a controller(s) system, e.g., as shown in FIG. 14, whether the controller(s) wiring terminal pins could to be changed to match the pin requirements of a unit model, etc. The controller may also be able to modify its controller wiring terminal 1610, 1615 based on requirements of the wiring of the unit model(s). When a controller uses modules 1720, the module may be able to change the requirements of its wiring terminal 1710, 1715 based on requirements of the unit models attached to those portions of the module.
FIGS. 18 and 19 illustrate moving unit models from one location on a controller to another. FIG. 18 at 1800 represent a portion of a controller user interface screen, such as e.g., that shown at FIG. 14. A three way valve unit model 1805 is in the two far right-terminal connectors 1815 of a module 1800. The terminal to the far right is of type A, and the one to the left of it is of type B 1810. There is a controller wiring terminal pin between the two Three Way Valves that is empty. As shown at 1900, using a touch-screen, a mouse, or a different user input method, a user may move the three way valve 1905 one terminal connector to the left 1915, leaving an unconnected terminal connector 1920 at the far right of the module The user is also able to switch the types of terminal connectors on the three-way value from “B-A” to “A-B” 1910. The choices listed here are just examples and are not intended to be exhaustive.

III. Computing Environment

With reference to FIG. 20, an exemplary computing environment, which may be a controller, a series of connected controllers, a series of connected controllers in conjunction with a computer, a controller in conjunction with a computer, or some combination of the above, includes at least one central processing unit 2005 and memory 2015, 2025. The processing unit executes computer-executable instructions and may be a real or a virtual processor. There might also be a vector or co/processing unit 2010 that enables fast vector processing. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 2015, 2025 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. For example, the memory can be volatile memory, e.g., static memory cells, as in FPGAs and some CPLDs; or non-volatile memory, e.g., FLASH memory, as in some CPLDs, or in any other appropriate type of memory cell. The memory stores software implementing described techniques and tools. The computer system may be distributed, with multiple processors and associated memory in different locations that communicate using wired or wireless network connections. These distributed computing nodes may run simultaneously run the same program using distributed computing techniques.
A computing environment, including controllers, satellite controllers, and modules, may have additional features. For example, the computing environment may include storage 2020 which may also include memory 2025, one or more input devices 2030, one or more output devices 2035, and one or more communication connections (all grouped under communication devices 2040). An interconnection mechanism such as a bus, controller, or network interconnects the components of the computing environment. Typically, operating system software stored in memory 2015, 2025 provides an operating environment for other software executing in the computing environment, and coordinates activities of the components of the computing environment. The computing system may also comprise one or more networks 2050: wired, wireless, or some combination, other peripherals 2055, such as printers, etc., and users 2045. The computer system 2000, like other suitable systems, may also include one or more computer-readable non-transient storage media 2060. Media 2060 may be of different physical types. The media 2060 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 2060 such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile, non-transient 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 2005. The removable configured medium 2060 is an example of a computer-readable storage medium 2060. Some other examples of computer-readable storage media 2060 include built-in RAM, ROM, hard disks, and other memory storage devices which are not readily removable by users 2045. A computer-readable medium should not be considered a signal; neither should a computer-readable memory be considered a signal.
The medium 2060 is configured with instructions 2070 that are executable by a central processing unit 2005; “executable” is used broadly to include, interpretable code, software interpreter code (e.g., bytecode and/or p-code), machine code and/or code that runs using a distributed system, for example. The medium 2060 is also configured with data 2065 which is created, modified, referenced, and/or otherwise used for technical effect by execution of the instructions 2070. The instructions 2070 and the data 2065 configure the memory or other storage medium 2060 in which they reside; when that memory or other computer readable storage medium is a functional part of a given computer system, the computer system may be configured by the instructions 2070 and data 2065.
Although an embodiment may be described as being implemented as software instructions executed by one or more processors in a computing device (e.g., general purpose computer, cell phone, or controller), such description is not meant to exhaust all possible embodiments. One of skill will understand that the same or similar functionality can also often be implemented, in whole or in part, directly in hardware logic, to provide the same or similar technical effects. Alternatively, or in addition to software implementation, the technical functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without excluding other implementations, an embodiment may include hardware logic components such as Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip components (SOCs), Complex Programmable Logic Devices (CPLDs), and similar components. Components of an embodiment may be grouped into interacting functional modules based on their inputs, outputs, and/or their technical effects, for example.
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

We claim:

1. A computer-implemented method comprising:

accepting a defined space representation into a controller, the controller comprising a processor, memory, and a user interface;

accepting a unit model from a list of predefined models displayed on the user interface, the unit model having wiring requirements and location within the defined space representation;

accepting a constraint;

calculating placement of the controller within the defined space representation based at least partially on the constraint;

determining a wiring route between the controller and the unit model based at least in part on the defined space representation; and

determining point mapping between the controller and the unit model based in part on the wiring requirements.

2. The method of claim 1, wherein accepting a constraint comprises accepting a constraint input by a user.

3. The method of claim 1, further comprising displaying the point mapping on the user interface.

4. The method of claim 1, wherein the unit model comprises a labeled unit attribute, and wherein the labeled unit attribute is capable of being displayed on the user interface.

5. The method of claim 1, further comprising calculating number of controllers needed based at least partially on the constraint.

6. The method of claim 1, wherein the constraint comprises minimizing labor, minimizing hardware, maximizing labor, maximizing hardware, or specifying fill rate of hardware.

7. The method of claim 3, further comprising a second controller and wherein the user interface is configured to allow a user to input a request to move the unit model to the second controller, and wherein the request rebuilds the wiring route and the point mapping.

8. The method of claim 7, wherein the controller further comprises a wiring module with a terminal wiring requirement, the controller operationally able to allow a user to modify the terminal wiring requirement of the wiring module, producing a modified wiring requirement, and upon such action the controller is operationally able to check the modified wiring requirement to determine match between the modified wiring requirement and a wiring requirements of a resource to be connected to a terminal associated with the wiring module.

9. A system which generates point mapping, the system comprising: a controller with a processor; a memory in operable communication with the processor; a user interface associated with the controller, 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:

accepting a defined space representation into the controller;

accepting a constraint;

10. The system of claim 9, wherein the program residing in memory allowing modification of controller wiring terminals modifies a controller terminal.

11. The system of claim 10, wherein the program residing in memory allowing modification of controller wiring terminals modifies a controller terminal based on user input.

12. The system of claim 11, further comprising a second controller and wherein the user interface is configured to allow a user to input a request to move the unit model to the second controller, and wherein the controller or the second controller rebuilds the wiring route and the point mapping.

13. The system of claim 9, further comprising a second controller, and wherein the calculating placement of the second controller within the defined space representation is based at least partially on the constraint.

14. The system of claim 9, further comprising modifying wiring terminals based on a user request.

15. The system of claim 11, wherein modifying the controller wiring terminal comprises the controller sending a signal to a module associated with the controller; the module modifying its hardware to match requirements of the user input.

16. The system of claim 15, wherein the user input comprises input indicating a user moving a unit model to a new location within the module.

17. The system of claim 16, wherein the user input comprises input indicating a user inputting information into a user interface screen associated with the controller.

18. A non-transient storage medium configured with code which upon execution by a controller having one or more processors coupled with memory-stored instructions performs a point mapping generation method, the method comprising:

accepting a constraint;

generating point mapping between the controller and the unit model based in part on the wiring requirements.

19. The non-transient storage medium of claim 18, further comprising the controller modifying a control point terminal on the controller to match at least a portion of requirements of the point mapping.

20. The non-transient storage medium of claim 18, further comprising the controller modifying a controller wiring terminal on a module associated with controller to match at least a portion of requirements of the point mapping.