Patent Application
20200386668
The present invention relates to the field of sensors and more particularly to a system of flexible and networked sensors.
Present-day sensors and data loggers are designed as a single device that works with an established protocol to communicate data over a sensor network to the user without sharing detailed configuration information. The present designs required that when a new device, such as a new type of physical sensor element, is introduced to the system, all parts of the system that interact with the data from that element must be updated with new firmware, software, drivers, or configuration tables. For instance, sensors built with the state-of-the-art BACnet protocol communicate the type of physical phenomenon sensed using a coded table embedded in the standard, which is only updated every few years. In the BACnet environment, introducing a sensor that measures a new type of physical phenomenon requires updating firmware on the sensor or data logger to which the element is attached, the BACnet network controller software, any user display software, and the standard itself. In another example, a networked sensor system may transmit data in a packet format that has a standardized packet layout and sensor-type encoding system that prevents a new physical sensor type, or new feature such as a higher resolution temperature reading, to be added to a cellular data logger without a firmware change to the cellular data logger and changes to every part of a sensor network or application that uses the data from the data logger.
The present invention relates to the field of sensors and more particularly how sensors are designed and networked. The invention is a method and system including an architecture to build a sensor device, data logger device, or network of sensor and/or data logger devices such that each element of the device or network contains all the information, including configuration information, commands, timing information, and math needed for higher-level elements to it without any configuration, software, firmware, or driver changes or updates required for the higher-level elements. This invention may also be used in other fields, such as the field of heating and air conditioning air handling units which are not strictly sensors but must be controlled in a similar manner via a multipart firmware and software architecture.
Several key concepts of the invention are:
Attention is now directed to several figures that illustrate features of the present invention:
Several drawings and illustrations have been provided to aid in understand the present invention. The scope of the present invention is not limited to what is shown in the figures.
The present invention relates to the field of sensors and more particularly how sensors are designed and networked. The invention is a method, system, and architecture to build a hierarchical sensor device, data logger device, or network of sensor/data logger devices such that each element of the hierarchy contains all the information, including configuration information, commands, timing, math, and parameters of the provided value needed for higher-level elements to it without any configuration, software, firmware, or driver changes or updates required for the higher-level elements.
Some of the key concepts of the invention are:
The present invention organizes the elements of an individual device into a hierarchical structure. The present invention views the elements of a network of devices as a hierarchical structure, even though the network of devices may be a mesh or other non-hierarchical configuration. The structural concepts between the elements of an individual device and a network of devices are the same. The term “element” is used to interchangeably describe the parts that make up a single device and the devices that make up a network of devices. In the current invention, a device may be a single physical device or a group of physical devices that are connected, or networked, such that the collective devices may function as a single cohesive unit.
In this description of the present invention, the terms “client” and “server” are used to describe how elements interact. Client elements consume data and configuration information from servers. Server elements produce configuration information and data for clients. An element may be a client, a server, or both.
Client elements are said to be higher in the hierarchy than a server from which they consume data and configuration information. Server elements are lower in the hierarchy than the client that may request data from it. Generally, a client element requests data and configuration information from a server one level lower in the hierarchy; however, this is not a requirement. A client element may request data or information from other levels. A client requesting data or information from any other level is within the scope of the present invention.
An element may be a server such that the element provides data and configuration information for client elements. An element may be a client element that consumes information and configuration information from other elements. An element may be both a client and server, where it may consume configuration information and data from one or more elements and provide configuration information and data to one or more other elements in the hierarchy.
Depending on the protocol or connection method used between two elements, the client may initiate and control information exchange, or the server may do so. The use of the term “client” or “server”, or the hierarchical nature of the elements, does not constrain the method of information exchange between elements.
In a particular embodiment of the hierarchical concept of a device shown in
Parts of a physical device or network designed according to the present invention are considered separate elements rather than parts of the whole. Each of the separate elements may be designed separately and then connected in a hierarchy such that each element is either a client element, a server element, or both.
The separate elements of the device or network are considered during the design stage. Each element may be designed independently and must contain all information necessary for client elements to use the element as a server.
The elements of a device or network are considered interchangeable if they may each be a server for the same client part of the device or network.
Each element in a device or system contains the configuration information necessary for client devices to make use of it. The configuration may include the commands and timing necessary to actuate parts of the element and/or the math necessary to perform certain functions with the results from the element. These concepts are detailed later in this description. Each element of a device uses a machine-readable description language that describes the element in detail. A particular machine-readable description language is based on the JSON language; however other syntaxes and methods may be used other than JSON with equal effectiveness. Any machine-readable description language is within the scope of the present invention.
A typical example of the description of a physical sensor element may include the following and other information:
Some items in the list of configuration information is common to prior art sensor systems, such as a serial number or a model. However, other parts are unique to the present invention. Two such unique parts are embedded commands that may be acted upon by clients and math in the form of formulas and/or tables that allow a client to interpret a result. By providing these two unique types of information a client does not need new software, firmware, drivers, configuration files, or setup to use a server element even if the server element was not considered when the client element was created. Further, a device made of elements with this level of description may be plugged together without any setup or configuration whatsoever.
A server component including a machine-readable self-description is necessary, but typically not sufficient to complete all tasks. The server typically needs to include machine-actionable commands and math formulas that allow a client to execute commands on the server. The commands that must be performed for the server to function are defined such that a client may perform the command sequences. Example commands include a command to trigger an element to read the value of a physical sensor; retrieve the value read from the physical sensor; put the element to sleep; power the element up; configure the element to log data over a period of time at a certain interval; and configure a device to alert the client device when an out-of-range value is detected.
In a particular embodiment, a sensor element, output device, or other element, which is a server for a data logger engine, exposes I2C commands embedded in JSON that allow the data logger engine to command the sensor component to take certain actions. These actions may include, but are not limited to, turning on or off an LED; telling a physical sensor to make a reading; retrieving data from the sensor; turning on or off a heater located on the sensor; and configuring an out-of-range alarm on the sensor. These actions may be physical actions, such as turning the LED on/off, or having the sensor make a reading. The actions may also retrieve data, and/or configure the sensor, such as setting the alarm threshold values.
An example of a command sequence that can be stored in the configuration of a physical temperature sensor element to cause the sensor to read the temperature is:
This example shows that two commands must be executed over an I2C interface with at least an 11 mS delay between the execution of the first and second command. The commands will require 4,841 micro-amp milliseconds of energy to complete.
An additional element of the command system can be a signal processing definition that enables a client to execute commands on a master using looping and control structures, such as “if statements”.
The following is an example of a signal-processing configuration for a high-resolution temperature sensor that may be included, along with additional configuration information, in the physical temperature sensor element provided above.
The above example allows the client to execute a loop that reads the temperature sensor 16 times using the provided I2C commands and average the result. The example uses a counter variable in register p5 for the loop; stores data in register p2 and p3, which may overflow into register p4; and a cascading bit shift operation in registers p2-p4. The signal-processing functions of the command section may perform math functions on the values. There may also be a separate formula in the sensor configuration. In the example above, if both are present, the signal processing is performed first, and the formula is performed on the result of the signal processing.
The command system includes a method to sequence commands in a required order, or hierarchy. It is common that commands must be performed in order to receive correct results. The action hierarchy guarantees that actions will happen in the intended sequence.
In a particular embodiment, a sensor component, which is a server for a data logger engine, exposes the required sequence of commands to perform sensor readings and math functions. For example, a temperature and humidity component may require that for a humidity to be accurately sensed, the client must first request that a temperature be sensed. Further, only after both the temperature and humidity are sensed, retrieved, and calculated, may dew point be calculated. In this case the action hierarchy would indicate that temperature must occur before humidity and that humidity must occur before a dew point calculation.
The math system allows a client to perform mathematical calculations on configuration data, sensor data, or other data provided by the server.
In a particular embodiment, a sensor component, which is a server for a data logger engine, exposes math formulas that allow the data logger engine client to convert the raw sensor readings retrieved into a useful value, such as a temperature in degrees Celsius. The sensor component may also expose math sequences or lookup tables that allow the client to adjust the value using data from a previous calibration.
The following is an example of the math stored in the configuration of a physical temperature sensor element to cause the sensor to read the temperature:
This example shows the math formula to be computed; the data layout; the units of the finished result; the resolution of the finished results; the maximum and minimum values, which are specified for the sensor; and the maximum and minimum safe values over which the sensor can compute values.
The machine-actionable math system and machine-actionable command system, when coupled with a prerequisite and priority system, allow a sensor value to be derived rather than be obtained from a direct physical reading. The sensor may be derived from any of the following:
In all cases, the calculations may be made using readings from physical sensors or other derived sensors. Therefore, complex systems may be created by deriving a sensor value from other derived sensor values. Derived sensors may be created by providing only the math necessary to compute a new sensor value from prerequisite sensors, or a derived sensor may contain commands to physical sensors and math to allow the execution of one or more physical sensor commands, as well as the math necessary to calculate a new value.
The present invention includes a set of required prerequisites of physical and derived sensors to determine the order in which sensors must be read and/or calculated. The configuration stored in each physical and derived sensor contains a set of values that indicates what prerequisites must be completed before this physical or derived sensor may be operated upon and a separate set of values of what this physical or derived sensor provides as prerequisites for use in calculations of other physical and derived sensor values.
In a particular embodiment of a small USB data logger with one physical sensor element, the prerequisite values are implemented as two bit fields; however, other implementations that perform the same basic functions may be appropriate for other sensor or network designs where values from multiple devices, or elements, must be considered.
In this embodiment, which includes a physical temperature sensor, a physical humidity sensor, a derived high resolution temperature sensor, and a derived dew point sensor, the following prerequisite requirements are encoded: the temperature sensor requires no prerequisites; the high-resolution temperature sensor needs no prerequisites; the humidity sensor requires no prerequisites; the dew point sensor requires the humidity sensor as a prerequisite and either the high-resolution temperature sensor or physical temperature sensor as a prerequisite.
In this embodiment, which includes a physical temperature sensor, a physical humidity sensor, a derived high resolution temperature sensor, and a derived dew point sensor, the following is prerequisites are supplied and thus encoded: the temperature sensor satisfies a prerequisite where its value is needed; the high-resolution temperature sensor provides a prerequisite where its value is needed and satisfies the prerequisites for the physical temperature sensor value; the humidity sensor satisfies a prerequisite where its value is needed; and the dew point sensor satisfies a prerequisite where its value is needed (even though in this example, there is no other sensor requiring dew point).
It is noted that the high-resolution temperature sensor is a derived sensor, which, in this embodiment, samples the physical temperature sensor sixteen times, other number of times, and then averages the result. However, the high-resolution temperature sensor does not list the physical temperature sensor as a prerequisite, because the derived high-resolution temperature sensor includes a command definition to collect the sixteen physical sensor values separately. In contrast to the derived high-resolution temperature sensor, the dew point derived sensor contains only the formula needed for dew point computation and requires prerequisite values from other physical sensors. Both methods of creating derived sensors, with and without embedded physical commands, are equally valid and are within the scope of the present invention. The data logger microprocessor element, which is a client to the physical sensor in this example, may be requested to provide dew point values by the interface element, which is a client of the microprocessor. If so, the data logger microprocessor would use the prerequisite information stored on the physical sensor element to determined that first the physical temperature or the high-resolution temperature must be evaluated including any commands or math found in the physical sensor element configuration; the physical humidity sensor must be evaluated including any commands or math found in the physical sensor element configuration either before, after, or at the same time as either temperature sensor; then finally the dew point may be computed using the math in the physical sensor element configuration.
When cases arise that two or more values may be computed in any order, such as in this case where either temperature value and the humidity value may be executed at the same time, a priority order can be applied to ensure the operations are consistent and executed in the same order. In more complex implementations, this priority order may be adjusted to allow multiple threaded operations to occur simultaneously.
In the dew point example, the temperature must be read first from a physical sensor; the relative humidity value is then read from a physical sensor. The relative humidity value may then need to be corrected using the temperature sensor reading, and finally, the temperature value and humidity value are used to calculate the dew point. Each step is defined in the configuration as a configuration for a sensor value with a priority order.
A derived sensor exposed by a server is self-described as is a physical sensor even though no physical sensor element exists. Instead of executing physical commands to retrieve the sensor data, the client is presented a set of math formulas and/or lookup tables that calculate a new sensor value from existing physical readings.
In one example, a temperature and humidity sensor component, which is a server for a data logger engine, exposes a dew point derived sensor. The dew point derived sensor contains all the configuration information for a sensor as if it were a physical sensor; however, the dew point sensor value is a math function based on physical temperature and humidity values. There is no physical dew point sensor, only a derived sensor made from a math function.
In one example, a corrosion sensor component, which is a server for a data logger engine, exposes three sensors: a physical temperature sensor, a physical voltage sensor, and a derived corrosion sensor. The derived corrosion sensor value is calculated from the voltage reading across an element, the temperature of the sensor, and a set of lookup tables and formulas.
The following example shows an implementation of a physical temperature sensor and a derived high-resolution temperature sensor configuration that samples the physical sensor sixteen times and calculates the higher resolution result. These example configurations are stored in a single physical sensor element to provide two separate temperature sensor values, one physical and one derived.
Example of a derived high-resolution temperature sensor configuration
The above example demonstrates the following concepts of the present invention: force-conversion, conversion-time, and read-conversion. These are examples of embedded commands with timing information. Conversion-formulas show an example of embedded math, and the priority fields show an implementation of the prerequisite and priority system. The examples also show the implementation of the parameters required to use the data provided by the sensor, even if the unit type is not defined in the client device. The examples also show the implementation of protections from under and over range, energy usage information to enable the client to make energy efficient choices.
Physical or derived sensors may be used to construct an Alarm, which is a special case of a derived sensor. A derived sensor may be used in logic equations to trigger that specific events should occur. An Alarm may contain additional command(s) and/or signal-processing configuration information that is only executed when the final value of the Alarm-derived sensor matches a conditional value.
Alarms may be simple, such as a derived sensor that compares the value of a physical temperature sensor with a maximum value outputting a Boolean true, represented by a non-zero result if the physical temperature sensor value is greater than the maximum value and a Boolean false, represented by a zero result otherwise.
A simple Alarm is described in the example below, which determines if a temperature has exceeded 0 degrees C. The Alarm fetches a previously computed value. The value is then compared to zero. If found to be greater than zero, a log entry is recorded with a timestamp and the value measured.
This simple alarm may also refer to a variable in the client for comparison rather than a fixed value in the example, allowing more flexibility in the configuration of the alarm. An Alarm may also cause other events to occur, such as lighting an LED, or other physical alert; reading other sensor values, either derived or physical or both; recording other sensor values; causing a client to start or stop or continue datalogging for a fixed or infinite number of log entries; triggering a physical action, such as starting an air conditioner, via a relay, network command, or other means; or alerting another client device in a network. Alarms and the actions taken if an Alarm meets a condition may also be separated in a configuration.
Alarms may also be complex. A complex alarm may be computed as any other derived sensor, including using the values of multiple physical or derived sensors.
An example of a complex alarm is a derived sensor that is Boolean true, non-zero in the current implementation, if an iteration over the logged values of a corrosion sensor find that the rate of corrosion is greater than a specific limit found in a national standard. Give a data log of temperature readings with corresponding voltage readings from a metal thin film conductance sensor, the complex steps to accomplish this goal may be as follows:
Complex alarms are typically not found in prior art products due to the special coding required. In the present invention, the configuration contains all the information necessary to derive a complex Alarm function so that no special or new coding is required.
Another example of a complex Alarm-derived sensor using the machine-actionable math system is to determine if a temperature probe has been in the food temperature danger zone for two hours or more. A further example of a complex Alarm is to determine if a temperature probe has been exposed to either a peak temperature sufficient to render insulin ineffective or has been in a temperature range that will degrade insulin for enough total degree-minutes for the insulin to be rendered ineffective.
With the machine-actionable math system, the server temperature sensor may expose either simple or complex alarms to a client without a requirement that the client has any previous programming related to the Alarm function.
The math system, signal-processing system, and data tables may be used in a configuration to provide all calibration information for a physical or derived sensor. Sensor values may be provided to a client uncalibrated or calibrated, as needed. An uncalibrated, or raw, sensor value may be stored in a data log and later calibrated when the value is needed by another sensor or by a client device. Additional calibration information, such as the calibration provider, uncertainty, expiration, calibration date, and calibration method, may also be included. The calibration table and other calibration information may be updated when a sensor is recalibrated.
The present invention may be summarized by reference to several figures and drawings:
Several descriptions and illustrations have been presented to enhance understanding of the present invention. One skilled in the art will know that numerous changes and variations are possible without departing from the spirit of the invention. Each of these changes and variations are within the scope of the present invention.
This application is related to, and claims priority to, U.S. Provisional Patent application No. 62/834,818 filed Apr. 16, 2019. Application 62/834,818 is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62834818 | Apr 2019 | US |
