SYSTEMS AND RELATED METHODS FOR PROVIDING

ENVIRONMENTAL INTELLIGENCE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001 ] This application claims the benefits under 35 U.S.C. § 1 19(e) of priority to U.S. Provisional App. No. 62/394,601 , filed on September 14, 2016, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] Various aspects of the present disclosure relate generally to systems and methods for providing environmental intelligence. More specifically, the present disclosure relates to systems and related methods for obtaining data, processing the data, analyzing the data, and providing environmental intelligence based thereon.

BACKGROUND

[0003] Owners of scientific grade automatic weather systems (AWS) may share a goal of providing accurate and precise weather-related measurements and data. Companies have acted as systems integrators by selling measurement and data acquisition systems, including hardware and software for dataloggers, to fill their client's needs for measurements and data. With respect to the use of dataloggers, for a long time it was the case that data needed to be collected and stored locally for a buffer period between data retrieval activities, which were frequently manually performed or accomplished through periodic direct network connections between electronic devices. Such an approach ensured a constant collection of data without interruption if network connections ever were lost or interrupted. As part of such an approach, clients tended to purchased measurement and data acquisition systems, and ensured that they were properly installed, maintained, and calibrated over the lifetime of the equipment. The clients also retrieved the measurements from the equipment, commonly located in remote areas, manually or via telecommunications or satellite. Once the data was collected, the owners then performed quality assurance and quality control on the data before the data was ready for decision makers in organizations who rely upon such information to make their decisions.

[0004] The paradigm has shifted as communication networks have expanded and improved all over the world. Any application that is in an urban or semi-urban setting now typically has access to some form (or multiple forms) of high-speed wireless communication, and even very remote applications now may have access to some form of satellite communication. This new paradigm puts a greater focus on the flow of data from a field measurement to the end-user making the decision or analysis. In response to these changing market realities, a new end-to-end solution that provides quality, fit for purpose data, combined with analysis, may fulfill changing needs by providing high-quality data at a lower price, and with reduced complexity. The provider of such a solution may be able to densify data collection networks, and provide clients with an enhanced view on environmental information, allowing the clients to streamline and improve their decision-making processes. The provider also may remove the need for clients to understand and manage the complexity of field installations and maintenance of hardware, data retrieval and management, as well as quality control and validation.

SUMMARY

[0005] Aspects of the present disclosure relate to, among other things, systems and related methods for providing environmental intelligence. Each of the aspects disclosed herein may include one or more of the features described in connection with any of the other disclosed aspects.

[0006] According to an aspect of the present disclosure, a method for providing environmental intelligence may include obtaining measurement data indicative of one or more characteristics of an environment. The method also may include processing the measurement data by applying one or more algorithms to produce processed data. The method also may include analyzing at least one of the measurement data and the processed data to produce analyzed data. The method also may include

communicating at least one of the measurement data, the processed data, and the analyzed data to a user. [0007] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform.

Placement of the environmental measurement device in communication with the online platform may cause the environmental measurement device to undergo an automatic configuration process, wherein the environmental measurement device may receive one or more operational parameters from the online platform.

[0008] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform.

Placement of the environmental measurement device in communication with the online platform may cause the environmental measurement device to undergo an automatic configuration process, wherein the environmental measurement device registers with the online platform to open a pathway to further communication between the online platform and the environmental measurement device.

[0009] According to another aspect of the present disclosure, an environmental intelligence system may include an environmental measurement device configured to generate measurement data indicative of one or more characteristics of an

environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform. The online platform may be configured to monitor one or more characteristics of the environmental

measurement device for at least a portion of a lifecycle of the environmental measurement device. [0010] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device, and metadata indicative of one or more characteristics of the measurement data, may be provided to the online platform. The online platform may be configured to gauge quality of the measurement data using the metadata.

[001 1 ] According to another aspect of the present disclosure, a system for providing environmental intelligence may include a plurality of environmental measurement devices configured to generate measurement data indicative of one or more characteristics of an environment. The system also may include an online platform in communication with the plurality of environmental measurement devices. Measurement data from the plurality of environmental measurement devices may be provided to the online platform. The online platform may be configured to compare measurement data from a first environmental measurement device to measurement data from at least one additional environmental measurement device to gauge quality of the measurement data from the first environmental measurement device.

[0012] According to another aspect of the present disclosure, a mounting assembly for an environmental measurement device may include a housing. The assembly also may include a first fastener is configured for coupling to the housing for securing the housing to a structure external to the mount. The assembly also may include a mounting plate configured to receive at least a portion of the environmental measurement device. The assembly also may include a second fastener configured for coupling to the mounting plate for securing the mounting plate to the housing.

[0013] According to another aspect of the present disclosure, an environmental measurement device may include a power source and a powered component coupled to the power source to receive power from the power source. The device also may include a processor and/or a controller, wherein the processor/controller is configured to set an operating parameter of the powered component to maintain the environmental measurement device at a power consumption level within a

predetermined range.

[0014] According to another aspect of the present disclosure, a method for updating a time setting of an environmental measurement device may include determining whether the environmental measurement device is in communication with an external online platform. The method also may include updating the time setting of the environmental measurement device at a predetermined frequency. The

predetermined frequency may be selected such that a maximum rate of updating is not exceeded, so that a level of power consumed by updating the time setting is within a predetermined range.

[0015] According to another aspect of the present disclosure, an environmental measurement device may include a first sensor configured to generate measurement data indicative of one or more characteristics of an environment exterior to the environmental measurement device. The device also may include a second sensor configured to generate measurement data indicative of one or more characteristics of an environment in an interior of the environmental measurement device. At least one of the measurement data of the first sensor and the measurement data of the second sensors may be used to set an operating state of the device.

[0016] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform. The environmental measurement device may be configured to perform a plurality of functions. The environmental measurement device may be configured to limit operation to only a subset of the plurality of functions when an operational parameter of the environmental measurement device falls outside of a predetermined range of values. [0017] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform. At least one operating parameter of the environmental measurement device may be automatically set upon the environmental measurement device being placed in communication with the online platform.

[0018] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform. The online platform may be configured to execute a recognition process to identify the environmental measurement device, and to set at least one operating parameter of the environmental measurement device upon recognizing the environmental measurement device.

[0019] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The device also may be configured to process the measurement data locally to produced processed data. The system also may include an online platform in communication with the environmental measurement device. At least one of the measurement data and the processed data from the environmental measurement device may be provided to the online platform.

[0020] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more characteristics of an environment. The device also may be configured to process the measurement data locally to produced processed data. The system also may include at least one signaling device in communication with the environmental measurement device. At least one of the measurement data and the processed data from the environmental measurement device may be provided to the signaling device to cause the signaling device to emit an alert indicative of the at least one of the measurement data and the processed data.

[0021 ] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an online platform. The system also may include an environmental measurement device remote from the online platform and in communication with the online platform. The environmental measurement device may be configured to generate measurement data indicative of one or more characteristics of an environment. The device also may be configured to process the measurement data into environmental intelligence about the environment from which the sensor took the measurement data. The device also may be configured to provide the environmental intelligence to an end-user via the online platform.

[0022] According to another aspect of the present disclosure, a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more

characteristics of an environment. The system also may include an online platform in communication with the environmental measurement device. Measurement data from the environmental measurement device may be provided to the online platform. The online platform may be configured to process the measurement data into

environmental intelligence about the environment from which the sensor took the measurement data.

[0023] According to another aspect of the present disclosure, an environmental measurement device may include a plurality of communications linkages. Each of the communications linkages may provide a pathway for communicating with a remote online platform. The device also may include a controller configured to determine the availability of each of the communications linkages, and automatically switch between communications linkages based on their availability to maintain at least one pathway for communicating with the remote online platform.

[0024] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the features claimed. Additional objects and advantages of the disclosed aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed aspects. The objects and advantages of the disclosed aspects will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary aspects of the present disclosure and together with the description, serve to explain the principles of the disclosure.

[0026] FIG. 1 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0027] FIG. 2 is another schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0028] FIG. 3 is another schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0029] FIGS. 4 and 5 show components of, and processes related to, a current sense circuit, in accordance with aspects of the present disclosure;

[0030] FIG. 6 is a perspective view of an environmental measurement device, in accordance with aspects of the present disclosure;

[0031 ] FIG. 7 is a schematic illustration of a base of the environmental measurement device of FIG. 6, in accordance with aspects of the present disclosure;

[0032] FIGS. 8 and 9 are tables showing Wi-Fi and power features, , in accordance with aspects of the present disclosure;

[0033] FIG. 10 is a schematic illustration of a base of an environmental measurement device, in accordance with aspects of the present disclosure; [0034] FIGS. 1 1 and 12 are schematic illustrations of hardware blocks of the base of FIG. 10, in accordance with aspects of the present disclosure;

[0035] FIG. 13 is a schematic illustration of a multi-protocol handling capability of the base of FIG. 10, in accordance with aspects of the present disclosure;

[0036] FIG. 14 is a circuit diagram of the multi-protocol handling capability of FIG. 13, in accordance with aspects of the present disclosure;

[0037] FIG. 15 is a schematic illustration of time-related aspects of an environmental measurement device, in accordance with aspects of the present disclosure;

[0038] FIGS. 16A and 16B are schematic illustrations of connector aspects of an environmental measurement device, in accordance with aspects of the present disclosure;

[0039] FIG. 17 is a circuit diagram of the connector aspects of FIGS. 16A and 16B, in accordance with aspects of the present disclosure;

[0040] FIG. 18 is a circuit diagram of an open collector output aspect of an environmental measurement device, in accordance with aspects of the present disclosure;

[0041 ] FIG. 19 is a circuit diagram for an onboard sensor of an environmental measurement device, in accordance with aspects of the present disclosure;

[0042] FIG. 20 is a schematic illustrations of the hardware blocks from FIGS. 1 1 and 12, with an on-board sensor block highlighted, in accordance with aspects of the present disclosure;

[0043] FIG. 21 is a circuit diagram of a software controlled programmable voltage capability of an environmental measurement device, in accordance with aspects of the present disclosure;

[0044] FIGS. 22-24 are perspective views of a base, bracket, and pole assembly, in accordance with aspects of the present disclosure;

[0045] FIGS. 25-28 show multiple views of components of the bracket assembly of FIGS. 23 and 24, in accordance with aspects of the present disclosure; [0046] FIGS. 29A and 29B are schematic illustrations of ways in which communication can be established in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0047] FIG. 30 is a schematic illustration of a bridge between an environmental measurement device and a web portal, in accordance with aspects of the present disclosure;

[0048] FIGS. 31 -33 are exemplary webpages for displaying data from an environmental intelligence system, in accordance with aspects of the present disclosure;

[0049] FIG. 34 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0050] FIG.35 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0051 ] FIG. 36 is a table listing descriptions of aspects of the schematically illustrated environmental intelligence system of FIG. 35, in accordance with aspects of the present disclosure;

[0052] FIG. 37 is a schematic illustration of a process for registering a device, in accordance with aspects of the present disclosure;

[0053] FIG. 38 is an screenshot of a webpage for account management in environmental intelligence system, in accordance with aspects of the present disclosure;

[0054] FIG. 39 is a screenshot of a webpage for purchasing resources in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0055] FIG. 40 is a screenshot of a webpage showing dashboards in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0056] FIG.41 is a schematic illustration of a multi-dashboard capability of a web portal of an environmental intelligence system, in accordance with aspects of the present disclosure; [0057] FIG. 42 is a manual data entry widget of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0058] FIG. 43 shows a multi-page display for a widget of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0059] FIG. 44 is a menu listing of a management webpage or portal of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0060] FIG. 45 is a display listing devices in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0061 ] FIG. 46 is a display showing device information in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0062] FIG. 47 is a display showing data information in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0063] FIG. 48 is a data information window in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0064] FIGS. 49-52 are symbolic representations of exemplary events that may take place in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0065] FIG. 53 is an administration or management webpage/interface for an environmental intelligence system, in accordance with aspects of the present disclosure;

[0066] FIG. 54 is a list of serial numbers and statuses displayed through use of the webpage/interface of FIG. 53, in accordance with aspects of the present disclosure;

[0067] FIG. 55 is an exemplary webpage from a web portal of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0068] FIG. 56 schematically depicts a capability of displaying different webpages to different entities in an environmental intelligence system, in accordance with aspects of the present disclosure; [0069] FIG. 57 is a schematic illustration of steps performed using an environmental intelligence system, in accordance with aspects of the present disclosure;

[0070] FIGS. 58A-58C are boxes showing logic rules for triggering indicators based on weather data in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0071 ] FIG. 59 is a schematic illustration showing relationships between components in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0072] FIG. 60 is a flow diagram showing a quality assurance/quality check process for an environmental intelligence system, in accordance with aspects of the present disclosure;

[0073] FIG. 61 is a schematic illustration of a geospatial data reference checking process for an environmental intelligence system, in accordance with aspects of the present disclosure;

[0074] FIG. 62 is a table showing types of data, their sources, and where they are stored, in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0075] FIG.63 is a schematic illustration showing relationships between an environmental measurement device and forms of metadata used in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0076] FIG.64 is a schematic illustration showing ways an environmental measurement device can be managed, in accordance with aspects of the present disclosure;

[0077] FIGS. 65 and 66 schematically illustrate scenarios in which operation of an environmental measurement device may be altered for survivability in an environmental intelligence system, in accordance with aspects of the present disclosure; [0078] FIGS. 67 and 68 schematically illustrate over-the-air update capabilities of an environmental intelligence system, in accordance with aspects of the present disclosure;

[0079] FIG. 69 is a state diagram showing states and events related to updating software, in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0080] FIG. 70 is a communication diagram of a dialog among a file client, net services, and a file server, in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0081 ] FIG. 71 is a flow diagram of the process of FIG. 70, in accordance with aspects of the present disclosure;

[0082] FIG.72 is a schematic illustration of a centralized sensor

profile/configuration catalog in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0083] FIG. 73 is a communication diagram of a dialog between an

environmental measurement device and a portal, in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0084] FIG. 74 is a schematic illustration showing mapping of a query to a file name in an environmental intelligence system, in accordance with aspects of the present disclosure;

[0085] FIGS. 75-77 schematically illustrate remote console access and command line interface capabilities of an environmental intelligence system, in accordance with aspects of the present disclosure.

[0086] FIG. 78 schematically illustrates multiple communication means by which an environmental measurement device can communicate with a cloud-based platform, in accordance with aspects of the present disclosure.

[0087] FIG. 79 schematically illustrates a communication means by which an environmental measurement device can communicate with a cloud-based platform via one or more intermediary devices (e.g., other environmental measurement devices), in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0088] Reference will now be made in detail to the exemplary aspects of the disclosure, examples of which are illustrated in the accompanying drawings.

Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0089] As used herein, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not necessarily include only those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. The term "exemplary" is used in the sense of "example," rather than "ideal."

Environmental Intelligence System (EIS) Overview

[0090] This disclosure describes aspects of an environmental intelligence system (EIS) that allows clients to leverage vast amounts of raw environmental sensor data and turn it into actionable insights. The EIS is facilitated by technological developments, including the evolution in communications, measurement technologies, and the rise of the Internet-of-Things (loT), combined with the growing demand for accurate weather data in business, government, and other sectors. The EIS may streamline the flow of environmental measurement data from field sensors to clients, and improve the decision-making process for clients by combining quality data with deep, intelligent analysis. The EIS may provide high-quality data at a lower entry price point and reduced operational complexity, opening the door to new market segments, and making measurement accuracy available to a larger population. The EIS also may support a group of clients who may not fully understand the physics behind measurements and data collection, whether they do not have enough knowledge or training, or they do not have the necessary time and infrastructure.

[0091 ] A few exemplary goals and features of the EIS include: (A) offloading sensing device functionality onto a cloud-based platform to reduce the complexity of the software and hardware in the EIS; (B) facilitating automatic configuration functionality for sensing device for ease of use; (C) utilizing metadata and other information for enhancing performance of sensing devices and quality of measurements; (D) harnessing Wi-Fi communications technology that may be used to link sensing devices with the cloud-based platform; (E) provisioning to allow smart devices (e.g., smart phones, 3G tablets, and the like) to communicate and provide some setup of metadata and configuration parameters, such as networking setup; (F) using digital measurements to avoid inefficiencies associated with using analog measurements from traditional analog dataloggers; (G) reducing power consumption; (H) transferring information to the cloud-based platform for storage, processing, and distribution; (H) laying the groundwork for a data-as-a-service (DaaS) offering to clients; (I) enabling multiple uses from an initial measurement. This list is not exhaustive. Additional or alternative goals and features are described below.

[0092] The EIS may include one or more new devices, including an

environmental measurement device (EMD) that may take measurements and accumulate data, and a cloud-based data management service or cloud-based platform. The EMD may bring together technologies that include data storage, Wi-Fi communication, a power controller, and an automatic configuration approach for smart sensors, requiring limited configuration. Configuration may be managed centrally through a web-based interface of the cloud-based platform that may push the configuration remotely to EMDs. The cloud-based platform also may manage the flow of data from the EMDs and provide automated quality assurance and validation functions, as well as the ability to provide data outputs to clients in various formats that may include automated reports, analysis tools, as well as the raw data when desired, or even direct connection with client corporate management/enterprise systems.

[0093] In one exemplary implementation, the EIS may provide a network of data collection points using a network of geographically spaced apart EMDs. The EIS may collect the data using the EMDs, perform quality assurance/quality checks (QA/QC) on the data, and process the data, before feeding the data to one or more clients, thereby simplifying their access to quality measurements for an increased number of locations, and allowing clients to focus more heavily on analysis and distribution. [0094] FIG. 1 shows exemplary aspects of an EIS 100. The EIS 100 may include one or more devices 102, for example, conventional hardware (e.g., dataloggers) and/or EMDs. The EIS 100 also may include a management engine or cloud-based platform 104. Data services 106 may be provided by the EIS 100. Data services 106 may include, for example, organizing and storing data. Environmental intelligence 108 also may be provided by the EIS 100. Environmental intelligence 108 may include, for example, information, generated after processing and analysis, that may be provided to clients to aid their decision-making processes.

[0095] FIG. 2 shows exemplary components of the EIS 100. The EIS 100 may include a smart sensor (SS) 1 10 that may take measurements and provide digital data based thereon. The EIS 100 also may include a base 1 12. The SS 1 10 may be operatively coupled to the base 1 12. Together, the SS 1 10 and the base 1 12 may form an EMD 1 14. In various embodiments of this disclosure, an EMD is described as having a sensor (e.g., SS 1 10) and a base (e.g., base 1 12), where the sensor and the base are individual components that are coupled to form the EMD. It should be understood, however, that components and operations of the base may be

incorporated into the sensor, or vice-versa. Stated another way, it is contemplated that all of the features of the sensor and the base may be integrated into a single device. This may include, for example, miniaturizing one or more components of the base, and integrating the components of the base into the sensor, to form the integrated single device. The components and functionality of the integrated single device may be the same as for an EMD with a base and a sensor that are individual devices that are then coupled.

[0096] The EIS 100 also may include an access point (AP) 1 16 for providing internet connectivity to the EMD 1 14, thereby connecting the EMD 1 14 to the cloud- based platform 104. The EIS 100 may act as a bridge, or a suite of technology that may provide integration of hardware, software, and communications technologies, allowing the EMD 1 14, and other devices like the EMD 1 14, to be easily deployed, simplifying the process of rendering information to one or more users 1 18, which may include clients. Other users 1 18 also may interact with the EIS 100 by, for example, sending information or instructions to the EIS 100 and/or receiving information or instructions from the EIS 100. The bridge also may include hardware that EMDs may be physically connected to, communications between the hardware and the cloud- based platform 104, which may include a cloud-based data management layer and a data management and analysis user interface accessible to client 1 18. The bridge may be sensor agnostic and may support downstream integration with client-side decision support systems. The bridge also may support and enforce a data standard for measurement metadata. Additional descriptions of these and other aspects of the EIS 100 are provided below.

[0097] The SS 1 10 may include a digital sensor that may be plugged into the base 1 12. The base 1 12 may support connection with a multitude of sensor types, including but not limited to gyroscopic, air temperature, surface temperature, relative humidity, moisture, heat, wind direction, wind speed, distance, flow rate, pressure sensors, and/or visual sensors (e.g., cameras). The SS 1 10 may have automatic configuration capability. This capability may simplify and reduce costs associated with sensor installation and maintenance. The base 1 12 may automatically recognize when a compatible SS 1 10 is connected, and may activate the SS 1 10 and collect its metadata. The EIS 100 may include a plurality of stations, at least some of which are EMDs with one or more SSs, that together form a network. It is contemplated, for example, that thousands of stations may provide data to the cloud-based platform 104, and their data may be offered to clients through one or more client-accessible portals. The EIS 100 is virtually infinitely-scalable upward by adding stations, adding clients, and, if needed, expanding the capacity of the cloud-based platform 104 to

accommodate. Additional descriptions of these and other aspects of SSs are provided below.

[0098] The base 1 12 may be configured to, for example: (A) communicate with the cloud-based platform 104 via any suitable communications link, such as Wi-Fi; (B) identify characteristics of the SS 1 10 and download the corresponding configuration parameters from the cloud-based platform 104 for setting up operation of the base 1 12 with the SS 1 10; (C) receive metadata from the SS 1 10; (4) take measurements with or without simple processing, such as: (1 ) sample; (2) maximum (with time of occurrence); (3) minimum ( with time of occurrence); (4) average; and (5) total; (D) transmit data and metadata to the cloud-based platform 104; and (E) update the configuration of the SS 1 10 from the cloud-based platform 104. Additional

descriptions of these and other aspects of bases are provided below.

[0099] It should be understood that any of the data processing and/or analyzing steps described in this disclosure as being performed by the cloud-based platform 104, may alternatively be performed by the EMD 1 14, and vice-versa. For example, by performing measuring and processing/analyzing at EMD 1 14 (e.g., in the base 1 12), the EMD 1 14 may have the ability to provide environmental intelligence to users without having to connect to the cloud-based platform 104. This feature may be advantageous when a communications link between the EMD 1 14 and the cloud- based platform 104 is unavailable or otherwise unreliable, or when attempting to reduce power consumption of the EMD 1 14 (since the EMD 1 14 may consume power to maintain communication with the cloud-based platform 104).

[00100] The AP 1 16 may be configured to provide an internet connection via Wi-Fi for the EMD 1 14 to communicate with the cloud-based platform 104. Exemplary types of APs are permanent AP (e.g., a permanent router) (FIG. 2), a mobile AP (e.g., a Wi-Fi hotspot provided by a smart device, such as a smart phone or 3G tablet) (FIG. 29A), and a Wi-Fi direct AP (FIG. 29B). Additional descriptions of these and other aspects of APs are provided below.

[00101 ] The cloud-based platform 104 may include a network of servers running software applications to deliver services to users. Utilizing the cloud-based platform 104 in the EIS 100 allows for simplification of the EMD 1 14 by offloading data handling and user interface functionality from the EMD 1 14 to the cloud-based platform 104. The use of the cloud-based platform 104 also may overcome firewall issues that are sometimes encountered by internet-connected devices. The cloud- based platform 104 may have the following capabilities: (A) provides an account for each user to log in to the cloud-based platform's website(s) or portal(s); (B) facilitates registration of EMDs to be able to communicate with the EMDs; (C) gets measurement configuration parameters from users; (D) stores configuration parameters of SSs; (E) receives measured data from EMDs and stores them; (F) provides for visualization of data in one or more dashboards (e.g., customized webpages); (G) provides the Coordinated Universal Time (UTC) for devices to auto-update the time; (H) provides a standard format for databases; and (I) allows for manual data entry by users. A provider of the cloud-based platform 104 may use the cloud-based platform 104 to manage devices remotely, allowing the provider to adjust configurations, manage metadata, and generally oversee operation of a network of connected devices. The cloud-based platform 104 also may have data management capabilities that may allow collection of data from remote devices using Wi-Fi, cellular (e.g., via a cellular network), or satellite communication (these forms of communication being embedded in the remote devices or operatively coupled to the remote devices), perform QA/QC, structure the data, provide web displays of the data, as well as provide for client downloads of the data. Additional descriptions of these and other aspects of the cloud-based platform 104 are provided below.

[00102] An exemplary configuration of entities associated with the EIS 100 is shown in FIG. 3. The entities may be arranged in a hierarchy, including the provider or vendor 120 on top, network owners (NOs) 122 one level down, and device owners (DOs) 124 one level down from the NOs 122. The provider 120 may provide the EIS 100 for the NOs 122, who may be users of the EIS 100. The NOs 122 may be clients of the provider 120, and may be the owners of the network of devices 126 (e.g., EMDs). Each of the NOs 122 may have access to the stored data of its own devices in the cloud-based platform 104. In the cases where an NO 122 wants to have its own private cloud service, the provider (as the administrator), may provide a separate cloud website for the NO 122 (with provisions for settings, configurations, scripts, events, etc.). Afterwards, the provider 120 may abandon its administrator access to the NO 122. The DO 124 may be the owner of one or more devices in the network of devices 126. The DO 124 may be responsible for the measurement site or field site 128, and/or may provide internet access to the device(s). The DO 124 may have access only to data of its own device(s) 126. Other configurations of entities are also contemplated. Additional descriptions of these and other aspects of the EIS 100 are provided below.

EMD Sensors

[00103] The EMD 1 14 may include the base 1 12, and the SS 1 10 (or multiple SSs) coupled to the base 1 12. SSs may have specialized circuitry and programming to enable users to configure and calibrate the sensor independent of a datalogger. Other sensors may be analog, and thus, may provide a physical response that may then be interpreted and transformed into a measurement by the datalogger through an analog to digital converter. In SSs, this may happen directly on/in the SS. Exemplary types of SSs may include those for measuring wind speed, wind direction, temperature, relative humidity, barometric pressure, rainfall, and/or any other suitable environmental conditions. Other SSs be added as client demand dictates.

[00104] The SS 1 10 may have automatic configuration capabilities, which may entail performance of one or more of the following functions: (A) auto-detection of a new SS connection; (B) identification of the SS type and obtaining of SS metadata (e.g., serial number, model, vendor, location, and/or any other suitable information about the SS); (C) downloading of corresponding configuration parameters of the SS from the cloud-based platform 104; and (D) measurement and recording, including digital measurement and recording. Using SSs may eliminate the reprogramming of an EMD when a sensor is replaced and/or reconfigured. Field installation and/or replacement of SSs can be carried out with minimal knowledge, infrastructure, and tools. No longer will the datalogger (or other measurement system) need to be reprogrammed by skilled personnel at the field site, which may be in a remote location. This may save the costs of using highly-trained technicians as well as retraining staff due to turnover, and their time and logistics, as the hardware may be simplified.

Moreover, using minimally-trained individuals, such as farmers or other entities with access to the field sites, to carry out simple cleaning and debris removal from the SSs ,may reduce the maintenance cost of the systems and may increase the data quality. Should one SS fail, a new one can be sent to the local individual for exchange by unplugging the old unit and plugging in the new unit. [00105] With respect to the above-described procedures, it is contemplated that SS metadata may be forwarded when the SS 1 10 is connected to the base 1 12. For example, the metadata may be pushed to a central cloud location to be captured by software running in the cloud-based platform 104. It also is contemplated that the EMD 1 14 may provide the metadata that may describe each individual data value. The ability to store and transmit metadata, such as metadata as defined by the World Meteorological Organization (WMO), may offer advantages. Metadata may include "data about data," and in some examples, may serve to qualify data. For example, the term metadata may be used in some contexts to describe digital data for weather station data. Metadata may be used in the

hydrometeorological field to organize electronic resources, provide digital

identification, and help support archiving and preservation of the data. The collection of field metadata can be performed manually, which may be a laborious task. Each sensor in a network may need to be monitored as to location, how the data was processed, the next time for calibration, serial number, and manufacturer, etc. Since the collection and attaching of metadata to actual measured data may be done manually, there is significant risk for entry errors or delays. The EIS 100, on the other hand, may obtain the metadata through its communications with SSs, which may transmit that information to the cloud-based platform 104, along with the data values via the EMDs. The metadata may be attached to the sensor data automatically.

Through this automatic reporting, it may be known when a site visit needs to occur to service the sensors.

[00106] Additionally or alternatively, limits may be placed on the SS 1 10. The following limits can be determined after finalizing the available data sources in the cloud-based platform and memory of the EMD 1 14: (A) a limit on the EIS 100 regarding the maximum number of SSs connected to the base 1 12; and (B) a limit on the EIS 100 regarding the maximum number of values returned by an SS to the base 1 12.

[00107] The interface between the SS 1 10 and the base 1 12 may be SDI- 12 (serial digital interface at 1200 baud), RS-232, and/or RS-485. SDI-12 is an asynchronous serial communications protocol for intelligent sensors. SDI-12 was developed for environmental monitoring applications and may be used for SSs in the EIS 100. SDI-12 may govern how an SS may communicate with other devices. Any sensor claiming to be SDI-12 compatible may accept a standard set of commands and conform to specific electrical and power standards. SDI-12 may support an

identification command that can be used for automatic configuration functionality. SDI- 12 also can handle metadata. SDI-12 also allows defining of higher level protocol requirements for consistent implementation of automatic configuration and metadata. RS-232 is another standard for serial communication transmission of data. It defines the signals connecting between data terminal equipment (DTE), such as a computer terminal, and data circuit-terminating equipment or data communication equipment (DCE), such as a modem. RS-485 is a standard defining the electrical characteristics of drivers and receivers for use in serial communications systems. The EMD 1 14 may be compatible with one or more of these protocols. The EMD 1 14 also may evolve to include compatibility with new protocols that emerge for SSs.

Automatic Configuration

[00108] A completely automatic configuration may be implemented to achieve true sensor plug and play capability. The first part of the process may begin with detecting the connection of a sensor (e.g., SS 1 10) or the removal of a sensor. This may be done by means of current-sense and/or by a physical detect input signal. Once a sensor connection is detected, a base (e.g., base 1 12) may leverage the SDI- 12 protocol and retrieve sensor identification information. The identification

information may then be forwarded to the cloud-based platform 104. The cloud-based platform 104 may then provide configurable information for the specific sensor and/or for the specific NO. These configuration parameters may include one or more of: (A) measure rate and/or intervals; (B) sensor trigger commands; (C) processing type (sample, min, max, avg.); (D) output interval; (E) power management; (F)

communications rate; and/or (G) diagnostics type.

[00109] To have a fully automatic SS 1 10 with automatic configuration capability, the base 1 12 may be able to detect the connection of a new SS, as well as identify the I/O interface type (SDI-12, RS-232, or RS-485). Different strategies are applicable for this purpose, including: (A) new connection detection, wherein: (1 ) the DO informs the base 1 12 about the new connection via a built-in webpage of the base 1 12; (2) boot-up detection (where the base 1 12 is re-started after plugging); (3) a button is pushed after plugging the SS 1 10 into the base 1 12; (4) scheduled checking; and (5) a trigger connector; and (B) I/O interface type identification, wherein: (1 ) the DO configures the I/O interface type by the built-in webpage of the base 1 12; (2) jumper switch; and (3) programmatic detection. It is contemplated that if a SS is replaced by a similar one, there may not be a need to inform the base 1 12 about the replacement, and the base 1 12 may continue working. In the case of the SDI-12 interface, the base 1 12 may recognize the sensor replacement by checking the serial number of the new SS.

[001 10] The base 1 12 may be configured for use in the EIS 100. When the SS 1 10 is connected to the base 1 12, the base 1 12 may forward identification information about the SS 1 10 to the cloud-based platform 104. The cloud-based platform 104 then may provide configuration parameters to the base 1 12 to acquire data from the SS 1 10 to meet applications requirements. Two exemplary types of configurations include NO-defined configurations and provider-defined configurations. NO-defined configurations may be determined by the NO of the device, and may include: (A) measurement interval (scan rate or sensor polling interval); (B) type of processing algorithms and stored data values (sample, maximum, minimum, average, and/or totalizing); (C) output interval; (D) data transmission interval; and (E) alarms (e.g., add an event triggering, when a certain condition is true for a data value, sending an e-mail, text message, or other alert). Provider-defined configurations may be common amongst compatible EMDs. Provider-defined configurations also may be backward compatible without customizations (e.g., may have the same configurations for multiple entities).

[001 1 1 ] Additionally or alternatively, the EMD's automatic configuration functionality may be enabled by current-sense technology. For example, a current- sense circuit may operate in-line between a power source (e.g., in the EMD 1 14) and the SS 1 10, with the function of detecting current flow. The current-sense circuit may operate in a dynamic range of 100 microamps to 2,000,000 microamps (2 Amps). In a scenario where the current-sense circuit detects current on the line, a signal may be sent to a processor to denote that the SS 1 10 has been plugged in to a base. Once the SS 1 10 has been established as being present, a software process may initiate further automatic configuration of the SS 1 10 via software settings. FIG. 4 depicts the current-sense process when current is detected. FIG. 5 depicts the current-sense process when no current is detected. In that scenario, a signal may be sent to a processor (e.g.., in the EMD 1 14) to denote that no sensor has been plugged in.

[001 12] Provisions may be made for making the EIS 100 compatible with sensors that may not be automatic configuration compliant. For example, an exemplary configuration may be implemented that may define parameters such as: (A) interface type; (B) baud rate; (C) parity bit, start/stop bit; and (D) measurement command format, to facilitate compliance. This may allow the EIS 100 to be merged with existing data acquisition systems to take advantage of the benefits of the cloud- based platform 104 and provide added value for clients who already have existing hardware installed in the field. Additionally or alternatively, the cloud-based platform 104 may be designed and built with the ability to import data from any source.

Additionally or alternatively, some existing data acquisition systems (e.g.., sensors, dataloggers, etc.) may have the ability to emulate the processes used by the EMD 1 14 to send data to the cloud-based platform 104. This emulation can be used to ingest data from the existing hardware without the need to add the EMD 1 14. Additionally or alternatively, the EMD 1 14 may be a modular system, and one of the modules may contain analog ports allowing the use of conventional sensors, and may provide analog-to-digital conversion capabilities.

EMD Base

[001 13] The base 1 12 may include components usable in many different environments. Structural and functional aspects of the base 1 12 will now be described. It should be understood that the base 1 12 may include any suitable controller/processor element (e.g. the "processor" shown in FIG. 7) for running firmware and software for controlling operation of its internal electronic components. While exemplary embodiments described in this disclosure may focus on an individual bases, it should be understood that multiple bases may be provided together. For example, multiple bases may be stacked or otherwise arranged in one location so that the number of sensors at that location may exceed what can be handled by a single base 1 12, thereby increasing sensing capacity at that location.

[001 14] FIG. 6 shows one example of the base 1 12, including an enclosure or housing 130 to protect internal components from the environment. The enclosure 130 may be Ingress Protection or International Protection (IP) rated. For example, enclosure 130 may be an IP67 outdoor-rated enclosure with room for: (A) additional ports and connectors; (B) wireless transmitters; (C) a Wi-Fi external antenna; (D) push buttons for data entry and/or commands; and/or (E) desiccant (changed with batteries and in the form of a replaceable/disposal cartridge). FIG. 7 shows a schematic of the base 1 12, highlighting exemplary internals. In one example, the components of the base 1 12 may be generic, and may interface with automatic configuration SSs to adapt the base 1 12 to particular environments. For example, the SS 1 10 may be tailored such that, when the SS 1 10 is operatively coupled to the base 1 12, the EMD 1 14 formed may be configured to obtain a particular type of data in a field site or environment. One end of the SS 1 10 may include a connector 132 for connecting to a complementary connector 134 of the enclosure 130. In one example, the base 1 12 may include two I/O connections or ports (not shown) configurable to SDI-12, RS-232, and/or RS-485. For example, the base 1 12 may include an

environmental circular connector and a terminal block. Additionally or alternatively, the SS 1 10 and the base 1 12 may communicate wirelessly using Wi-Fi, cellular (e.g., via cellular network), satellite, Bluetooth, or other radio-frequency communication protocol, and/or a near-field communication device.

[001 15] The end of the SS 1 10 opposite the connector 132 may include one or more elements 136 for taking measurements. The element 136 may be an elongate cylindrical member having a rounded tip. The enclosure 130 is shown as being rectangular with the connector 134 on its front face. It should be understood, however, that any suitable shape or configuration may be employed with respect to both the enclosure 130 and the SS 1 10.

[001 16] The base 1 12 may have the following features and functionalities: (A) the base 1 12 may communicate with the cloud-based platform 104, the SS 1 10, and/or other bases, via a network, such as over the Internet or a local- or wide-area network using Wi-Fi, cellular (e.g., via a cellular network), satellite, Bluetooth, and/or other radio-frequency communication protocol, and/or a near-field communication device, for communicating with other suitably-provisioned devices; (B) the base 1 12 may identify sensor types and download corresponding configuration parameters for sensor types from the cloud-based platform 104; (C) the base 1 12 may host a built-in webpage to facilitate communicate with the DO; (D) the base 1 12 may receive metadata from SSs and the DO; (E) the base 1 12, via its operatively coupling to the SS 1 10, may take measurements and perform simple processing (e.g., sample, maximum, minimum, average, totaling); (F) the base 1 12 may transmit data and metadata to the cloud-based platform 104; the base 1 12 may be readily registered, configured, and/or duplicated to create a high-density network of stations; (G) the base 1 12 may be self-powered; (H) the base 1 12 may provide real-time access to data via the Wi-Fi connection and the cloud-based platform 104; (I) the base 1 12 may provide tracking features over a geographic area; (J) the base 1 12 may update configurations from the cloud-based platform 104; (K) the base 1 12 may contain one or more analog ports allowing use of conventional sensors; and (L) the base 1 12 may provide analog- to-digital conversion for converting data from conventional sensors for use in the EIS 100.

[001 17] For the EIS 100, most user-interface functionality, as well as data storage, may be provided by the cloud-based platform 104. To exchange data with the cloud-based platform 104 or otherwise connect to the Internet wirelessly, the EMD 1 14 may use Wi-Fi or similar communications means, such as cellular, satellite, Bluetooth, and/or other radio-frequency communication protocol, and/or a near-field communication device. The EMD 1 14 may include a combination of different communication means. The EMD 1 14 may determine the availability of each of the communication means, and automatically switch between communication means based on their availability, to maintain at least one pathway for communicating with the cloud-based platform 104.

[001 18] Specifications of an exemplary Wi-Fi module for the base 1 12 of the EMD 1 14 may include one or more of the following:

[001 19] (A) Temperature range: -50°C to +60°C (or best commercially- available option).

[00120] (B) Low power consumption (e.g., one or more low-power modes of operation).

[00121 ] (C) FCC and other world-wide certificates.

[00122] (D) Wi-Fi Direct connectivity.

[00123] (E) Compatibility with the IEEE 802.1 1 protocol, which has low power consumption.

[00124] (F) A security protocol (some Wi-Fi modules use HTTP to establish communication, but HTTPS may be desired for higher security).

[00125] (G) Adaptive Wi-Fi parameters (the following parameters may influence the power consumption of the Wi-Fi module in transmission and receiver modes: (1 ) working mode (transmit (Tx), receive (Rx)); (2) packet size; (3) data rate; (4) RF power level; and (5) distance range. According to the specifications of the Wi- Fi module, the optimum value of the above parameters may be determined adaptively for Tx and Rx working modes separately to meet power consumption requirements of the EMD 1 14). The parameters may be determined and/or implemented by a controller/processor element in the EMD.

[00126] (H) External antenna (the Wi-Fi module should carry the external antenna connection in addition to, or as an alternative to, an integrated (onboard) antenna for desired coverage).

[00127] (I) Wi-Fi Direct (a Wi-Fi standard that enables devices to connect with each other without requiring a wireless access point and Internet connectivity. Only one of the Wi-Fi devices needs to be in compliance with Wi-Fi Direct to establish a Wi-Fi Direct connection. The Wi-Fi Direct capability may be particularly useful in the Wi-Fi module for the following cases: (1 ) Wi-Fi network configuration and (2) no internet connection configuration. With respect to Wi-Fi network configuration, a configuration webpage may be hosted by the Wi-Fi module to communicate with the Wi-Fi module for Wi-Fi network configuration. For downloading the webpage without a pre-configured Wi-Fi connection, either Wi-Fi Direct or a mobile/portable AP capability of smart devices may be used to configure using a web browser. With respect to the no-Internet-connection configuration, in the case that a smart device is supposed to provide the Internet connection for the EMD 1 14, it is possible that there may be a failure in the Internet connection or the smart device may not have access to a cellular network. In such a scenario, Wi-Fi Direct may be used to transfer data from the EMD 1 14 to the cloud-based platform 104.

[00128] (J) The overall power consumption of Wi-Fi communication may be high, and in general, the power consumption in Tx mode is higher than in Rx mode. To meet the power consumption requirements of the EMD 1 14, the EMD 1 14, and or its Wi-Fi module, may have low-power modes, such as: (1 ) standby; (2) sleep; and (3) deep sleep.

[00129] (K) To have a user interface with the DO, custom webpages may be displayed to them from a web server built into the Wi-Fi module. The user interface may be helpful for the following cases: (1 ) Wi-Fi network configuration; (2) registering the EMD 1 14 to the cloud-based platform 104; (3) informing the EMD 1 14 about a new sensor connection and I/O interface type (SDI-12, RS-232, or RS-485); and (4) cloud connection feedback (e.g., connection status, data transmission status, etc.).

[00130] (L) Provided that a mobile AP or Wi-Fi Direct connection is in use, a Wi-Fi module may be activated only in the presence of the DO for data collection. Therefore, provision of a wake-up button for the Wi-Fi module may be included to wake up the module to establish the Wi-Fi connection.

[00131 ] (M) Wi-Fi direct button enables the Wi-Fi Direct capability of the Wi-Fi module to work as the access point.

[00132] ^» (N) According to the type of the power source (e.g., internal battery, external battery, solar cell, AC power supply, etc.) the EMD 1 14 may have three power modes: (1 ) Low Power Mode (LPM); (2) Medium Power Mode (MPM); (3) High Power Mode (HPM).

[00133] (0) In the case of LPM and MPM with the Mobile AP (or Wi-Fi Direct), a limitation on the Wi-Fi connection duration may be set (e.g., 2 minutes) for the cases that the Wi-Fi network is not available or Wi-Fi connection is not possible. After this Wi-Fi unavailability timeout period, the Wi-Fi module may go to the sleep mode again. If the data transmission takes longer than this duration, the Wi-Fi module may stay on until told to disconnect or until the network is no longer available.

[00134] (P) The cloud connection interval (recording interval may be set by the NO). The guaranteed battery life of the EMD 1 14 may facilitate at least one connection per day. A table of the battery life against the cloud connection interval may be provided for the user.

[00135] (Q) Wi-Fi retransmission/retry rate restrictions, shown in FIG. 8, may be applied on the incidences of Wi-Fi retransmission or retry when connection with the cloud-based platform 104 is lost, or the cloud-based platform 104 is otherwise not available. The retransmission/retry rate may differ depending on whether the base 1 12 is in low, medium, or high power modes.

[00136] As shown in FIG. 7, the base 1 12 also may include a memory element 138. Memory 138 may include non-volatile computer memory. Memory 138 may provide a backup/buffer for sensor data when Wi-Fi communication may not be available. The capacity of memory 138 may include, for example, any of: (A) 24 months of data, including timestamp plus 20 data values per day; (B) 20 data values per day, shared between multiple sensors; (C) the minimum required memory for data (with IEEE4 byte float), or about 175 KB; (D) the minimum required memory for data and configurations, or about 225 KB; and (E) more than 20 data values per day, made possible by shortening the data collection interval. Additionally or alternatively, a table for a user in the cloud-based platform 104, showing the maximum storage time against the output interval (recording of the measurements in the EMD 1 14 in terms of values per day; e.g., 24 months at 20 values/day, 12 months at 40 values/day, 6 months at 80 values/day), may be provided for selecting memory capacity. The available nonvolatile memory of the base 1 12 for data may determine data limits.

[00137] Power to the base 1 12 may be provided by a battery (see FIG. 7), such as an external battery operatively coupled to the base 1 12 by an external battery connection 140. The battery may be a lithium battery, or any other battery having suitable temperature ratings. The battery may be configured to have an operational life of 6 months or more. The battery may be replaceable. This may be facilitated by the battery being externally accessible. A damaged or depleted battery may be replaced with a new one. Additionally or alternatively, the battery may be charged via one or more solar panels (not shown) operatively coupled to the battery and/or to the base 1 12 via a solar panel charging port 142.

[00138] The charge status of the battery (e.g., battery life) may be determined and/or may be displayed to a user. The battery life may be affected by: (A) sensor type; (B) measurement interval; and (C) cloud connection interval

(recording interval). A battery life calculator can be provided for the user in the cloud- based platform 104 for managing these and other settings and configurations. A power switch (not shown) may be included in a power management module 144 of the base 1 12. The power switch may switch off the SS 1 10 in time to eliminate quiescent current draw. The base 1 12 also may include a backup battery 146 for powering one or more components.

[00139] According to the type of power supply available (e.g., internal battery, external battery, solar panel, and/or AC power supply), the base 1 12 may operate in one of a plurality of power modes. Properties of exemplary power modes (e.g., low, medium, and high power modes) are shown in FIG. 9. The power modes may, for example, affect the retransmission/retry parameters outlined in FIG. 8.

[00140] To provide global time and date to the EIS 100, the base 1 12 may be equipped with a low-power real-time clock (RTC) 148 (FIG. 7) for recording times in universal time coordinated (UTC). The local time zone of the base 1 12 may be entered as a configuration. The data representation to the user (e.g., database or graph) can be shown in the user's local time. The local time as well as the UTC may be shown in the built-in webpage of the EMD 1 14. A checkbox may be shown in a configuration window in the cloud-based platform for displaying the daylight savings time (DST). The time(s) may be auto-updated when the EMD 1 14 is connected to the cloud-based platform 104. In the case of lack of Wi-Fi or cell coverage, the time(s) may be updated manually in the built-in webpage of the EMD 1 14 by the DO. A maximum rate of time-updating may be set. For example, to conserve power, time- updates may be conducted, at most, once a day. The RTC 148 may be set manually, or may be updated by the cloud-based platform 104 whenever the battery has been disconnected, unless a backup battery 146 is present that maintains the time settings. A table of battery life versus the measurement interval for different types of sensors may be provided for users. For example, the output interval for measurements may be provided to, and may be configurable by, the NO. Data obtained by the EMD 1 14 may be timestamped. The storing time of the data may be specified by the timestamp obtained from the RTC 148. The available non-volatile memory 138 of the base 1 12 for the data may determine data limits.

[00141 ] In one example, the DO can log-in to the cloud-based platform 104 and enter data manually in a dashboard or other graphical user interface. The type of manually-entered data can be indicated by the provider or the NO in the cloud- based platform 104. In one example, the manually-entered data may include, for solid precipitation, type (e.g., snow, hail, or sleet), amount on ground (trace), and amount of snow water equivalent (SWE); and for liquid precipitation, amount on ground (trace). Different units may be configurable by the provider or NO, and may be selectable in the manual data entry dashboard by the DO. The timestamp (local time) and the time zone may be provided by the DO. The local timestamp may be converted to the UTC timestamp by, for example, scripts in the cloud-based platform.

[00142] A feature for testing sensor measurements and cloud connectivity may be provided in the built-in webpage of the EMD 1 14. For example, the feature may include processes that may initiate measurement and cloud connection to immediately confirm operation of the EMD 1 14. A feature for debugging the

functionality of the EMD 1 14 and its connection(s) with the cloud-based platform 104 may be available through the built-in webpage of the EMD 1 14. Power constraints may be considered with respect to running of the debugging functionality in low power mode applications, since Wi-Fi communications may be highly energy consuming. The base 1 12 may include an internal factory reset button 150. Actuation of the factory reset button 150 may cause the base 1 12 to return to its factory state or settings in case, for example, the base 1 12 is not operating as desired. Additionally or alternatively, the factory reset command can be sent to the base 1 12 by using the built-in webpage of the EMD 1 14, provided that a Wi-Fi connection is available for communicating the command to the base 1 12.

[00143] FIG. 10 shows aspects of another exemplary base 152. It is contemplated that any combination of features shown in FIGS. 6, 7, and 10 may be utilized in the bases 1 12 and 152. In FIG. 10, the base 152 is an assembly having an EMD core enclosure 154 around a Wi-Fi module 156, a power controller (power management) 158, a RTC 160, a system-on-a-chip (SoC) printed circuit board (PCB) 162, and an onboard cell modem 164 for communicating over a cellular network. The base 152 also may include a power storage enclosure 166 for housing one or more batteries 168. A solar panel 170 of the base 152 may captures solar energy for charging the batteries 168 and/or powering the assembly. The base 152 also may include a multi-sensor connectivity interface 172. The EMD core enclosure 154, power storage enclosure 154, solar panel 170, and multi-sensor connectivity interface 172 may be separate, modular components of the base 152. As such, the base 152 may be modified by adding or removing these and other modular components.

[00144] A high level view of hardware blocks of the base 152, showing how they relate, along with exemplary chips and part numbers, is shown in FIGS. 1 1 and 12. Using boxes around hardware blocks, FIG. 12 shows how power can be turned on and off to hardware blocks, by managing power-related hardware blocks 174, 176, 178, 180, 182, and 184 to conserve power and extend battery life of the base 152.

[00145] Additionally or alternatively, the base 152 may have the capability to run three different protocols (SDI-12, RS-232, and RS-485) that can be electronically selected and set via software based on configuration

parameters/requirements. The base 152 can support all three protocols on a single physical connector, as shown in FIG. 13. An exemplary circuit diagram showing an implementation of this feature is provided in FIG. 14.

[00146] Additionally or alternatively, as exemplified in FIG. 15, a networked time source 186 may act as a RTC module/monitoring system for the EMD time. The EMD time may be managed at least in part via the internal RTC 188 (running, e.g., from a 32,768 Hz crystal). Upon booting up, the networked time source 186 also may check with a backup RTC 190 of the EMD 1 14. The networked time source 186 may be used as a reference for time if there is time drift outside of a predetermined range. For example, if there is a time drift of 10 seconds.

[00147] Additionally or alternatively, the base 152 may include two connectors 192 and 194, shown in FIGS. 16A and 16B. The two figures show that the battery 168 and the solar panel 170 can be plugged into ports of either of the connectors 192 and 194. The wiring has been configured so that any of the two sources can be plugged into any of the two connectors 192 and 194, and the base 152 may still receive power. An exemplary circuit diagram showing an implementation of this feature is provided in FIG. 17.

[00148] Additionally or alternatively, an open collector output or port can be used to assist and control an external device operatively coupled to the base 152, by providing switching capability from the base 152. The open collector output may act like an electronic on and off switch for the external device. This may allow for the control of power flow to external devices that can be plugged into the base 152, such as an electronic smart signage system. An exemplary circuit diagram showing an implementation of this feature is provided in FIG. 18. The external device may include a signaling device configured to emit visual, audio, and/or tactile alerts. For example, the base 152 may send measurement data and/or processed measurement data to the signaling device. Based on the data, the signaling device may emit an alert based on the data. The processed measurement data may be received by the base 152 from the cloud-based platform 104. Alternatively, the processed measurement data may be generated at the base 152, and may be sent directly to the signaling device. The data may also be sent to the cloud-based platform 104, or communication with the cloud- based platform 104 may be avoided.

[00149] Additionally or alternatively, the base 152 may include an onboard sensor 196, used to measure moisture levels inside the base 152 to ensure there are no leaks in the enclosure 154, or condensation trapped in the enclosure 154 due to high humidity. The onboard sensor 196 can also measure the temperature of components, such as the PCB 162, to detect whether operation is normal (e.g., within a predetermined range of temperature) or if maintenance may be required. An exemplary circuit diagram showing an implementation of this feature is provided in FIG. 19. The hardware block 198 corresponding to this feature is highlighted in FIG. 20.

[00150] Additionally or alternatively, it is contemplated that not all sensors connected to the base 152 necessarily run on 12V of power. Accordingly, a software- programmable voltage configuration function may provide control over the amount of power flow to sensors that may require other than a nominal 12V input. The software- controlled programmable voltage function can manage a power range of between 3.06V to 14.4V. An exemplary circuit diagram showing an implementation of this feature is provided in FIG. 21 .

[00151 ] Additionally or alternatively, major components/modules of the base 152, for example at the firmware level, may be replaced/upgraded/swapped for newer features and additional capabilities. This may allow the base 152 to be adapted to fulfill third-party needs and perform in multiple and/or different user environments.

Universal Bracket Assembly

[00152] A base 200, which may be similar to bases 1 12 and/or 152, may be deployed on a post 202, as shown in FIG. 22. The base 200 may be mounted on the post 202 by a universal bracket assembly (UBA) 204, shown in an assembled state in FIGS. 23 and 24. The UBA 204 may mount devices on posts ranging from, for example, 3"-8", including fluted posts, wooden posts, and square posts. Exemplary components of the UBA 204 include a housing 206 (FIG. 25), a mounting plate 208 (FIG. 26), a mounting plate extension 210 (FIG. 27), and an enclosure bracket 212 (FIG. 28).

[00153] The housing 206 (FIG. 25) may include a rectangular-shaped body 214. A first side (not shown) of the body 214 may be configured to engage the post 202. In one example, the first side may be contoured to be complementary to the shape of the post 202 for a close fit between the body 214 and the post 202. The body 214 may have a second side 216 opposite the first side. An upper region 218 of the body 214 may include a pair of loops 220 and 222 for receiving a flexible banding 224. The flexible banding 224 may extend around the post 202, through the loop 220, across the second side 216 of the body 214, through the loop 222, and back around the post 202. Portions of a channel 226, formed in the second side 216 of the body 214, may extend between the loops 220 and 222, for receiving the banding 224 to help seat the banding 224 on or in the body 214. A lower region 228 of the body 214 may include a similar arrangement of loops, channel portions, and banding.

[00154] Recesses may be formed on the second side 216 of the body 214. For example, a pair of recesses 230 and 232 may be formed thereon, with one of the recesses in the upper region 218 and the other in the lower region 228, along opposing side edges 234 and 236 of the body 214. The recess 230 in the upper region 218 may include an aperture 238 therein for receiving a fastener (not shown). The aperture 238 may be threaded for receiving a bolt. The bolt may be used to secure the housing 206 to the post 202 in combination with, or in place of, the banding 224. FIG. 24 shows the housing 206 secured to the post 202 without banding 224 to support a solar panel 240. The recess 232 in the lower region 228 may be similarly structured for similar operation.

[00155] A channel 242 may be formed on the second side 216 of the body 214. The channel 242 may extend from proximate a top edge 244 of the body 214 to a bottom edge 246 of the body 214. Apertures 248, 250, 252, 254 may be formed in the channel 242. One or more of the apertures 248, 250, 252, 254 may be threaded for receiving a bolt (not shown) for securing other components of the UBA 204 to the housing 206, as described below. [00156] The mounting plate 208 (FIG. 26) may be X-shaped, with four arms 256, 258, 260, 262 extending outwardly from a central portion 264. The central portion 264 may include a rectangular, raised spine or ridge 266 extending from proximate an upper edge 268 of the central portion 264 to a lower edge 270 of the central portion 264. Apertures 272, 274, 276 may be formed on the ridge 266. The ridge 266 may be received in the channel 242 of the body 214. The apertures 272, 274, 276 of the ridge 266 may be aligned with some of the apertures 248, 250, 252, 254 in the channel 242, and bolts (not shown) may be inserted through the apertures to secure the mounting plate 208 to the housing 206. It is contemplated that the same bolts may also secure the housing 206 to the post 202. The arm 256 may include a slot 278 extending from proximate an upper edge 280 of the arm 256 into the arm 256, the slot 278 terminating before reaching a lower edge 282 of the arm 256. An enclosure 284 of the base 200 may include a protrusion 286 on a rearward-facing surface (e.g., a T-shaped protrusion, such as a partially-inserted bolt, not shown) that may be slidably received in the slot 278 for securing (e.g., hanging) the enclosure 284 on the mounting plate 208. The arms 258, 260, 262 may include similar slots for receiving similar protrusions of the component, for added security. The enclosure 284 may be removed from the mounting plate 208 by sliding the protrusions back out of the slots. FIGS. 23 and 24 show the enclosure 284 mounted on the post 202 via the housing 206 and the mounting plate 208.

[00157] The ridge 266 may define a rectangular hollow or recess 288. The mounting plate extension 210 (FIG. 27) may include a rectangular member dimensioned for receipt in the recess 288 and in the channel 242 of the body 214. The mounting plate extension 210 may include apertures 290, 292, 294, 296, 298, 300, arranged in two sets: an upper set 302 proximate an upper region 304 of the mounting plate extension 210, and a lower set 304 proximate a lower region 308 of the mounting plate extension 210. In use, the lower region 302 of the mounting plate extension 210 may be inserted into the channel 242 of the body 214. One or more of the apertures of the lower set 304 may be aligned with one or more of the apertures in the channel 242 of the body 214, and bolts (not shown) may be inserted through the apertures to secure the mounting plate extension 210 to the housing 206, and to the post 202. The upper region 304 of the mounting plate extension 210 may extend upwardly away from the housing 206 in a cantilevered fashion. The upper region 304 of the mounting plate extension 210 may be positioned in the recess 288 of the ridge 266 of the mounting plate 208. One or more apertures of the upper set 302 may be aligned with one or more of the apertures in the ridge 266, and bolts (not shown) may be inserted through the apertures to secure the mounting plate 208 to the mounting plate extension 210, resulting in the mounting plate 208 being secured to the post 202, via the mounting plate extension 210 and the housing 206, in a location longitudinally offset (upwardly) from the housing 206. The enclosure 284 may be secured to the mounting plate 208 in the manner described above. Alternatively, the upper region 304 of the mounting plate extension 210 may be secured to the housing 206, while the lower region 308 of the mounting plate extension 210 may be secured to the mounting plate 208, resulting in the mounting plate 208 being secured to the post 202 in a location longitudinally offset (downwardly) from the housing 206.

[00158] The enclosure bracket 212 (FIG. 28) may include a rectangular plate or body 310. Body 310 may include one or more apertures 312 and 314 for receiving one or more fasteners (e.g., screws or bolts, not shown) for securing the enclosure bracket 212 to a component of the base 200. The component may contact a front side 316 of the body 310. One or more arms 318, 320 may extend transversely away from a rear side 322 of the body 310. The arms 318, 320 may, for example, extend perpendicularly from an edge of the rear side 322, or from closer to the center of the rear side. The arms 318, 320 may be supported at their base ends, proximate the rear side 322, by one or more gussets 324, 326, 328, 330, that may help prevent the arms 318, 320 from buckling under loading. One or more flanges 332 and 334 may extend transversely from the free ends of the arms 318, 320. The flanges 332 and 334 may, for example, extend perpendicularly from the free ends, such that the flanges 332 and 334 may be parallel to the body 310 and may overlap the body 310. The flange 332 may include a slot 336 therein, the slot 336 extending inwardly from a lower edge 338 of the flange. The flange 334 may include a similar slot 340. In use, the flanges 332 and 334 may be positioned relative to protrusions (not shown) of the housing 206, such that the slots 336 and 340 are aligned with the protrusions. The flanges 332 and 334 may be brought down onto the protrusions to slide the

protrusions through the slots 336 and 340, thereby securing the enclosure bracket 212 to the housing 206, and to the post 202 on which the housing 206 is secured. The protrusions may include, for example, fasteners (e.g., bolts, not shown) that may be partially-inserted into the apertures 248, 250, 252, 254 of the housing 206, and in some instances, into the post 202. The enclosure bracket 212 may be removed from the housing 206 by moving the protrusions back out of the slots 336 and 340. The arms 318, 320 may support the component of the base 200 in a location radially offset (outwardly) from the housing 206. FIGS. 23 and 24 show a battery enclosure 339 mounted on the post 202 via the housing 206 and the enclosure bracket 212. While not depicted, it should be understood that one or more wires, cables, or other electrical connectors may link one or more of the components of the base 200 on the post 202. It also is contemplated that the electrical connectors may be routed through one or more apertures and passages in the post 202, so that their exposure to the

environment may be limited.

Communications

[00159] Communications between the EMD 1 14 and the cloud-based platform 104 may be managed by integration of one or many communication

components and protocols that may include functionality for connectivity via a wireless network, such as over the Internet or a local- or wide-area network (LAN or WAN), using Wi-Fi, cellular (via a cellular network), satellite, Bluetooth, or other radio frequency communication protocol, and/or a near-field communication (NFC) device, for communicating with other suitably-provisioned devices. The communication components may be integrated directly into the base 200 of the EMD 1 14. The communications components may be housed in an enclosure with other components, or may be an independent component of a modular assembly. For example, the communications components that may their own enclosure. [00160] In one example, shown in FIG. 2, communications may be provided by the Wi-Fi AP 1 16, which may allow the EMD 1 14 to connect to the Internet for communicating with the cloud-based platform 104. In this example, the AP 1 16 may be a permanent AP (PAP), such as a wireless router. The AP 1 16 may provide permanent/continuous access to the Internet. Additionally or alternatively, in another example, where PAP may not be available, the owner of a smart device (e.g., smart phone, 3G tablet, etc.) may utilize a smart device 342 as a Wi-Fi hotspot (mobile AP or MAP) for the EMD 1 14 to communicate with the cloud-based platform 104 (FIG. 29A). Additionally or alternatively, in case the smart device 342 is not in an area with cell or Wi-Fi coverage, the smart device 342 is not a cellular device, and/or a data plan is not available for a cellular smart device 342, the EMD 1 14 can communicate with the cloud-based platform 104 in steps (see FIG. 29B). For example, a first step may include, using Wi-Fi Direct (which may provide a Wi-Fi connection between two machines without an internet connection), the EMD 1 14 may transmit data to the smart device 342 by using an application running on the smart device 342. A second step may include, when access to the Internet is obtained, the application in the smart device 342 transmitting the stored data to the cloud-based platform 104 (e.g., via the AP 1 16). Additionally or alternatively, updated configurations can be downloaded from the cloud-based platform 104 and conveyed by the smart device's application to the EMD 1 14 by Wi-Fi Direct. Activation of the EMD 1 14 in the cloud-based platform 104 may be performed when the EMD 1 14 has access to the Internet using PAP or MAP, because activation may be accomplished more efficiently using online communication between the EMD 1 14 and the cloud-based platform 104.

[00161 ] A controller/processor element of the EMD 1 14 may monitor the possible communications linkages between the EMD 1 14 and the cloud-based platform 104 to determine their availability. The controller/processor also may switch between possible communications linkages. For example, the EMD 1 14 may switch from a first communications linkage to a second communications linkage if the first communications linkage becomes unavailable while the second communications linkage is available. Additionally or alternatively, the switch may be based on trying to use an optimal communications linkage (e.g., fastest, least power-consuming, most reliable) based on one or more performance criteria. By switching when needed, the controller/processor may ensure that at least one pathway remains open for data to flow between the EMD 1 14 and the cloud-based platform 104.

[00162] Additionally or alternatively, the EMD 1 14 may have onboard multiple capabilities for connecting to the cloud-based platform 104, including, but not limited to: (A) onboard Wi-Fi capabilities/protocols; and/or (B) onboard cellular connectivity/protocols. The EMD 1 14 may switch from one capability to another for connectivity based on availability, available power, connection speed, and/or any other suitable factors. Additional or alternative aspects related to these connection capabilities are depicted and described in FIGS. 78 and 79. FIG. 78 schematically illustrates multiple communication means and steps by which the EMD 1 14 may communicate with the cloud-based platform 104. FIG. 79 schematically illustrates components and steps for a communication means by which the EMD 1 14 may communicate with the cloud-based platform 104 via one or more intermediary devices (e.g., other EMDs).

Cloud-Based Platform

[00163] FIG. 30 shows aspects of a bridge between the EMD 1 14 and a portal 348 for providing data services and intelligence to clients. As shown, the EMD 1 14 may be in operative communication with the cloud-based platform 104, which may include a cloud-based loT software platform. It is contemplated that the cloud-based platform 104 may be bi-directional. For example, the cloud-based platform 104 may manage the EMD 1 14 by, for example, pushing configuration instructions and/or other data to the EMD 1 14; and the cloud-based platform 104 also may obtain information from the EMD 1 14 in the form of, for example, measurements, metadata, and/or any other information generated by or related to the EMD 1 14. The cloud-based platform 104 may be secure, and may provide different levels of access depending on the characteristics of the entity requesting access. For example, employees of the provider may be granted a high level of access to the cloud-based platform 104, and may be able to utilize many (or all) of its features. The provider's partners and clients may be provided with lower levels of access. The level of access/security may be specifically tailored to the entity, such that different entities may have different levels of access/security based on their needs.

[00164] In use, the EMD 1 14 may obtain data at a field site, and the cloud- based platform 104 may obtain the data from the EMD 1 14. The cloud-based platform 104 may store the data in a repository 344. Third party libraries and/or services 346 may obtain the data from the cloud-based platform 104. An example of a third party library and/or service is a geographic information system (GIS). The GIS may capture, store, manipulate, analyze, manage, and/or present the data, along with any other suitable spatial or geographical data that may be used for graphing and/or forecasting. A portal 348 running on the cloud-based platform 104 may obtain the data from the GIS for viewing and/or use by a client or other end user that has access to the portal 348. Additional and/or alternative aspects of the cloud-based platform 104 are described below.

[00165] The cloud-based platform 104 may include data integration and volume management components and functions. In one example, the cloud-based platform 104 may retrieve data from stations (e.g., EMDs) every 15 minutes, although the measurements could be more frequent (e.g., every 5 minutes). In addition, the provider may want to access data from surrounding third party weather stations when available, and with a similar frequency, if possible. The third party weather stations may include any weather station within proximity of the network, including, for example, any National Weather Service, government managed, and/or privately managed weather station; any other weather station owned by a municipality; and/or any other weather stations owned by a State Department of Transportation or provincial Ministry of Transportation. Exemplary third party libraries may include location data, local measurements, local forecasts, third party measurements, National Weather Service measurements, National Weather Service forecasts, radar data, lightning data, and the like. A user interface of the cloud-based platform 104 may provide the ability to display data from all data sources. [00166] The cloud-based platform 104 also may include QA/QC management components and features. Data that is loaded into one or more repositories of the cloud-based platform 104 may be automatically checked for anomalies. These verifications may include abnormal parameters such as excessively high or low temperatures, dew points above the air temperature, and/or drastic changes in temperature in comparison to previous measurements. Any missing data or non-responsive stations may also be flagged. Battery levels dropping below a predetermined threshold may also be identified.

[00167] The cloud-based platform 104 may provide the web-based portal 348 as a user interface for clients and other users. The portal 348 may display interactive graphs and reports generated by the cloud-based platform to present measurement data and analyses. For example, a graph showing historical data over 24 to 48 hours may be displayed. The graph may be dynamic so as to allow users to drill down into more detailed data and/or modify the time scale of the graphs. An example of an interactive time-based graph that may be provided is shown in FIG. 31 . Additionally or alternatively, the cloud-based platform 104 may, through the portal 348, display geospatial data through a web-based mapping interface that may be queried and adapted to display environmental measurements. The interface may also be capable of displaying GIS data from various sources, displaying multiple GIS layers, querying of geospatial features, theme-based displays, limited spatial queries

(distances and areas), heat maps, 3-D measurements, map printing, and/or may be Open Geospatial Consortium (OGC) compliant. The cloud-based platform 104 may also provide the ability to store and access documents, mainly pictures related to specific conditions of each station over time, for display on one or more interface(s).

[00168] In one example, the user interface may have different views, including, for example, an application specific view (e.g., for municipal public works users or other specified entities), as well as a public view (e.g., for the general public), to share location specific weather measurements. The user interface may be composed of a series of screens that present a list of measurement stations as well as detailed views for each of those stations. The list may also be viewed through an interactive map interface. The entry screen may be the map view that may present all stations with an underlying map base of satellite imagery or road network (e.g., Google Maps or OpenStreetMap). These stations may include any station that has been included in the network for that specific client. This view may be toggled to a list view of those same stations. The icons used to identify each station may be a symbol indicative of one or more conditions (e.g., indicating the likelihood of freezing in the next 12 hours for road weather stations), with red tinting for a high likelihood of a condition being present, orange for a medium likelihood, and green for a low

likelihood. Additionally or alternatively, the current surface temperature, wind direction, and other conditions may be displayed, if available.

[00169] An example of a map-based view displaying a network of station locations is shown in FIG. 32. FIG. 33 is yet another example of a map-based view displaying a network of station locations A pop-up window may be displayed when the cursor is placed above a station (mouse over or click). The popup may present a summary view of the current station measurements as well as potential freezing and health indicators. The popup also may display a graph with the history of surface and air temperature over the last 24 to 48 hours. An additional click in the popup window may direct to a new screen that may present a detailed view for the selected station. This may first present the station description (metadata), photo if available, as well as a summary graph showing historical and forecasted data for air and surface temperature as well as dew point. This graph may cover 24 hours before and after current time. The graph may be dynamic so the user may zoom in (reduce the time scale) or out (increase the time scale). If wind speed and direction are not measured at the selected station, a measurement from the nearest available location may be displayed using a distinctive symbology (e.g., italics). A graph showing the history over 24-48 hours may also be displayed. A similar offering may be provided for rainfall, which may be sourced from another station when available and displayed with a distinctive symbology. Another section of the detailed view may show the history of the station status (battery level, data retrieval, calibration, service visits, etc.). In addition to these windows, a network summary report may be available from the main page. This report may provide an overview of the network, including, the number of stations by type, and/or by status (active or not), as well as potential freezing status summary. Any weather alerts, watches, or special advisories issued by National Weather Services also may be displayed at this network summary level. Additional or alternative aspects of the cloud platform are described below.

[00170] FIG. 34 shows a more detailed representation of the cloud-based platform 104, and lists categories of features, including data management features (e.g., collection/aggregation of data, inline data QC/QA, rollup of data, de-duplication of data, data compression, transformation(s) of data, data lifecycle management, and metadata identification), processing features (e.g., use of algorithms, machine learning, training, regression, classification, and clustering to process data), analytics (e.g., algorithmic logic, machine learning, training, reinforcement, regression, classification, and reduction to analyze data), and presentation features (e.g., visualization, real-time display, time-series, interactive, multi-layered, indicator guidance, decision guidance, and forecasting for presenting data). FIG. 35 shows a detailed view of building blocks (e.g., modules, functions, hardware) of the cloud- based platform 104. These aspects may be additions to, or alternatives to, the aspects of the cloud-based platform 104 described above. The cloud-based platform 104 may include components for enabling a multitude of functions. These components may be separated into server-based services 350 (below the dashed line 352) and an application specific layer 354 (above the dashed line 352). The table shown in FIG. 36, provides further explanations of the depicted components and functions.

Additional or alternative descriptions of components and functions are provided below.

[00171 ] Any suitable type of cloud-based platform may be used in the EIS 100, including infrastructure-as-a-service (laas), platform-as-a-service (PaaS), and software-as-a-service (SaaS) types. Providers of laaS may offer computers, including physical and/or virtual machines, and other resources. To deploy the applications, cloud users may install operating system images and their application software on the cloud-based platform infrastructure. In this model, the user may patch and maintain the operating systems and the application software. Providers of PaaS may deliver a computing platform, typically including an operating system, a programming language execution environment, a database, and a web server. Application developers can develop and run their software solutions on such a cloud-based platform without the cost and complexity of buying and managing the underlying hardware and software layers. For SaaS, users may be provided with access to application software and databases. Cloud providers may manage the infrastructure and platforms that run the applications. The following description is based on adopting PaaS, but other cloud- based platforms also may be used in the EIS 100.

[00172] The cloud-based platform 104 may be made up of elements, the first of which are cloud clients. Cloud clients may include entities of the cloud-based platform 104 that have ownership and resources. A cloud client can be a parent or a child to another cloud client, thus providing a strict control hierarchy of access. The most common scenario to envision is a main application adding users, who add devices they own. When a user logs into the application, it will have stored the key (credential) for that user's cloud client in the hierarchy. The user only sees child cloud clients (devices, in this case) they own. Thus the application provides the linkage when the user logs in to the key for that user's cloud client in the hierarchy.

[00173] The EMD 1 14 is one type of cloud client. Cloud clients, aside from representing physical electronic devices, also may represent users, applications, and vendors. The cloud-based platform 104 may manage a database of client elements, their hierarchy of ownership, and their resources (data, rules, scripts, metadata, etc.), in addition to providing access to the outside world for writing and reading data contained in them. Cloud clients may have one or more of the following characteristics: (A) ownership of other clients or may be owned by other clients, with the cloud client being able to access clients and resources it owns but not others; (B) resources, such as data, rules, scripts, and dispatches; (C) resource Identifiers (RIDs) and Client Identifier Keys (CIKs); (D) metadata information such as time zone or other info; E) one or more names (e.g., friendly name and/or alias name); (F) limits, such as limits on the number of data ports, events, daily SMS and e-mails; (G) information kept about when the cloud was created, updated, etc.; and/or (I) activation status. [00174] A cloud client in the cloud-based platform 104 may include a single element that may be mapped into the cloud platform's catalog by its resource identifier (RID). All information about this cloud client may then be found in a separate cloud platform database. The RID may function as a private key that locks away everything for the cloud client. If access to the cloud client is granted, resources, metadata, etc., associated with the cloud client, may be accessible. Cloud clients may have a CIK that is assigned by the cloud-based platform 104. The cloud client may store the CIK in nonvolatile memory, and may use the CIK for subsequent interactions with the cloud-based platform 104. Cloud clients may contain resources. The resources may include things such as data ports, data rules which can be scripts or events, metadata, and dispatches. Each resource may have limits on time series data history. The cloud client can access its own data resources and those owned by the cloud clients by using either a direct RID or by using an 'alias' for the resource or client.

APIs

[00175] Additionally or alternatively, the cloud-based platform 104 may include an application program interface (API), which may include a set of routines, protocols, and tools for building software applications, guiding interactions between software components, and/or programming graphical user interface (GUI)

components. The API may, for example, provide a link with the third party libraries and/or services (such as GIS, or others). The cloud-based platform 104 may include plug-ins and/or gateways that may provide software that gives the cloud-based platform 104 and/or its components added functionality; hosting and/or backup components for providing storage and access to webpages, and for backing up the storage and webpages; development operations; and/or system management components to, for example, facilitate collaboration of software developers and/or other information-technology professionals, and/or to automate the process of software delivery and infrastructure changes; a customer service desk component for interfacing with end users; and a product lifecycle management component for facilitating replacement, configuring, and/or updating of any hardware and software components of the EMD 1 14; and a field services toolbox for handling installation, maintenance, and/or repair of hardware components in the field.

[00176] The cloud-based platform's APIs may include services that perform specific tasks. Some of the APIs may send data to be stored in a data port for a cloud client. Other APIs may include function calls that may create resources for a cloud client, create a child cloud client, and/or read out a set of data. Cloud clients in the cloud-based platform 104 can have resources, which may include data ports, data rules, and dispatches. Each of these can be accessed through APIs, to create, modify, write, and read. Data ports may be used to store data with timestamps, as time-series based information. The data could be simple integer or float values for sensors, or it could be string information in large formatted packets of data, firmware files, etc. The time-series history retention can be controlled by number of points, time period, or memory storage. This data may be available on-demand for data rules and scripts to process, or for API function calls, such as read. One type of data rule may include script applications that have access to all of the cloud client's resources, to use them for creating more advanced conditional rules or create algorithms to process data in the cloud-based platform. These scripts may have access to the cloud client's other resources as variables and functions, and may have the ability to call dispatches. Another type of data rule type may include simple logical statements that can be applied to data ports over a number of points and/or time. For example, if a data port value is greater than x, y times, over a time period n, then it is true; otherwise it is false. Logical data rules can be attached to multiple dispatches. Dispatches may include requests out from the cloud-based platform 104. Most communication may be done with the APIs as client requests and responses from the cloud-based platform 104. Dispatches allow for the cloud-based platform 104 to send information out, whether it is email, SMS, XMPP, and/or HTTP. Dispatches may include essentially ready-to-go messages that may be triggered for sending with a packet load. Triggers may include data rule logic statements or script function calls.

[00177] The cloud-based platform 104 may include a data API. The data API may be an HTTP-based API for writing to and reading from the cloud-based platform 104. In one example, an EMD's code may open a connection to the cloud- based platform's server address documented in the API, send the data in the API format, including the CIK so the cloud-based platform 104 may identify who was sending the data and where to put it, the data port's alias, and its value to write. The cloud-based platform 104 may receive this data value and place it into that data port's data store with a time-stamp from when it received it. There may be multiple procedures associated with reading and writing data, including:

[00178] (A) The POST method may be used for writing into the cloud- based platform. One or more data ports of the alias with a given value can be written. The cloud client (e.g. device, portal) may be identified by the CIK. Data may be written with the server timestamp as of the time the data was received by the server. Data may not be written faster than a rate of once per second with this API.

[00179] (B) The GET method is used for reading from the cloud-based platform. By using the following request, the most recent value from one or more data ports with the alias can be read. The client (e.g. device or portal) to read from may be identified by the CIK. If at least one alias is found and has data, data will be returned.

[00180] (C) Hybrid writing/reading, where the method entails writing one or more data ports of the alias with the given value, and then reading the most recent value from one or more data ports with the alias. The cloud client (e.g. device, portal, etc.) to write to and read from is identified by the CIK. In general, writes occur before reads.

[00181 ] The cloud-based platform 104 may include a user datagram protocol (UDP) API that may provide a low-overhead interface that allows cloud clients with limited data bandwidth requirements (e.g. cellular data) to send data to the cloud- based platform 104. This API may use a UDP packet that encapsulates both identification information and data payload. Data being sent from the cloud client may be sent over a UDP socket. A CIK and one or more alias (resource) names may be included in the body of the UDP packet. Multiple cloud client resource values can be written in the body of a single UDP packet, with each cloud client resource being listed by its resource alias name, '=', and its value. Protocol and Data Format

[00182] The EMD 1 14 may communicate with the cloud-based platform 104 using HTTP protocol. For example, the EMD 1 14, or any other cloud client, may submit an HTTP request message to a server of the cloud-based platform 104. The server, which may provide resources such as HTML files and other content, may return a response message to the cloud client. The response may contain completion status information about the request, and/or may contain requested content in its message body. Exemplary HTTP responses may include: (A) OK (indicating a successful request, and requested values being returned); (B) No Content (indicating a successful request, but with nothing being returned); (C) Client Error (indicating that there was an error with the request); and (D) Server Error (indicating that there was an error with the request on the server). For greater security with respect to the communications, HTTPS may be used rather than standard HTTP protocol.

[00183] The cloud-based platform 104 may provide a standard database format for stored data. Additionally or alternatively, the cloud-based platform 104 may use a data interface API to retrieve data from the cloud. Then, the data may be stored in a database format. Three methodologies may be applicable for representing data in a database format: (A) fully-cloud approach (e.g., the data interface API may be used in a general-purpose cloud server (e.g., Google Cloud, Windows Azure, etc.) that may support standard database formats; with this approach, a user (e.g., a client) may interact with a second cloud platform; (B) local software (e.g., the data interface API may be in different languages (Java, C++, and Python), and may be used to develop a local software running at the user's computer to retrieve data and store the data in a database format); and (C) web-based database service (e.g., the data interface API can be applied for retrieving data, and data may be represented in a database format by applying a web-based database service such as WISKI).

Cloud Client Management

[00184] The cloud-based platform 104 may include a provisioning interface configured to help initialize and manage large numbers of connected devices (e.g., EMDs). The provisioning interface may accommodate multiple entities, including:

[00185] (A) Vendor (Provider): An entity that may be producing or otherwise supplying devices for the EIS 100. The vendor may also be the provider or administrator of the cloud-based platform 104. The vendor may: (1 ) create models; (2) manage model configurations; (3) add/remove serial numbers from a model; (4) add/remove content (firmware/configuration update) files from a model; and (5) manage model access rights.

[00186] (B) Network owner: An entity that owns and/or is deploying the devices. The network owner may: (1 ) add devices that have been pre-configured by the vendor; (2) enable devices for activation; and (3) release ownership of a device.

[00187] (C) Device: An entity that is deployed and that interacts with the cloud-based platform 104. An exemplary device entity is the EMD 1 14. The device may: (1 ) retrieve an authentication key (CIK) by activating an enabled serial number; and (2) download authorized content (firmware/configuration updates).

[00188] The cloud-based platform 104 may include device management components and functions. Entities associated with the EIS 100 may deploy a series of measurement stations, including one or more EMDs, to form a network of stations that may be viewed as a cohesive group, as there may be information sharing between stations. For example, focused road weather stations may be based on the EMD 1 14, and may be under the provider's control. As such, the road weather stations may be managed using an loT device management solution in the cloud- based platform 104. The solution may allow tracking of all stations within a network, connecting to the stations, managing of their configurations, and retrieval of data from the stations.

[00189] In one example, the cloud-based platform 104 may include components and functionality to add a new device (e.g., an EMD), which may generate a new cloud client with a CIK. Data sources, scripts, and other resources may be added to the device, and the CIK may be copied to the device's application code. Activation may be the first step to all subsequent interactions with the cloud- based platform 104. A device must activate itself in order to gain access to its cloud profile and related client model characteristics. The activation sequence may include the sending of: (A) a unique serial number and/or MAC address; (B) a vendor ID; and (C) a client model name, to the cloud-based platform 104, and receiving a CIK back. The device may then store the CIK in non-volatile memory and may use the CIK for subsequent interactions with the cloud-based platform 104.

[00190] Additionally or alternatively, an exemplary process for registering (e.g., enabling and activating) the EMD 1 14, or other device, into the cloud-based platform 104 is shown in FIG. 37. A device may be registered by the DO to be able to communicate with the cloud-based platform 104. The device may be enabled in the cloud-based platform 104, and then the device may activate itself by its serial number (SN). Each device may be provided with a unique SN. The SN may be the MAC address of the device, for example. Valid SNs may be listed in the cloud-based platform 104, and each SN may be activated only one time (unless deactivated and activated again). The device may be activated in the cloud-based platform 104 to be able to communicate with the cloud-based platform 104. However, the device may have to be added (enabled) to the cloud-based platform 104 by the NO by its unique SN prior to being activated in the cloud-based platform 104. There may be a default time to live (TTL) of, for example, 24 hours, for devices to activate once the SN has been enabled by the NO. Alternatively, another process may eliminate the need for enabling by the NO and the 24 hours TTL. This other process may entail using self- enabling and self-activating devices. The process may include using the provisioning API to automatically add a device. Each NO of the EIS 100 may be known by a unique client model name in the cloud-based platform 104, which may act as a network ID for a network of devices, with a unique RID (OWNER_RID). The OWNER_ RID may be used by the provisioning API to add a device automatically. The cloud- based platform 104 may include a web server application containing the list of

OWNER_RIDs of all cloud client models. Hence, the device may send an "add device" request as well as its client model name and SN to the web server application, and the server may communicate with the cloud-based platform 104 to add and activate the device. Then, the web server application may obtain the CIK of the activated device from the cloud-based platform, and provide it for the device.

[00191 ] Additionally or alternatively, automatically adding and activating a device may include: (A) the DO opening the local built-in webpage hosted in the EMD 1 14; (B) the DO entering the client model name; (C) the DO pushing a "registration" button; (D) the EMD 1 14 communicating with the web server application; (E) the EMD 1 14 being enabled by the server application, where the OWNER_RID and SN may be used for adding the EMD 1 14 by the provisioning API; (F) the web server application receiving an RID from the cloud-based platform 104 for the enabled EMD 1 14; (G) the EMD 1 14 being activated by the web server application; and (H) the EMD 1 14 receiving its CIK from web server application. If the handshaking process of registration is interrupted for a predefined duration, the process may be ended and restarted again.

[00192] Additionally or alternatively, a cloud client model may be utilized to add new devices, such as new EMDs. The cloud client model may include a predefined device profile. The profile may, for example, be created by the

vendor/provider. The device profile may copy a clone whenever a user adds a new device of the same client model type. Besides creating this copy automatically, the device may use the provisioning interface and/or a provisioning API to activate and receive the CIK automatically without any manual copying of the CIK to the device. This may facilitate the addition of new devices so that a device network can be scaled up quickly without being slowed down by the need for manual copying or interference. Cloud client models may be unique to vendor accounts, which may be a prerequisite to create cloud client models. Each cloud client model may have one or more of the following attributes:

[00193] (A) A unique name for the client model, assigned to each NO. The name may be created by the vendor, and sent to the NO. The NO may provide the identifier for the DOs to be able to activate the devices by, for example, using the built-in webpage of the EMDs. [00194] (B) The ability to create a clone, which may be a generic device that has been set up with data sources, data rules, scripts, and dispatches that the vendor wants to copy each time a new device is added.

[00195] (C) List of serial numbers, which may be unique identifiers for devices. The serial numbers can be the MAC addresses of the EMDs. When a device activates using the provisioning API, it may call in with the vendor ID, model ID, and this unique identifier. If this unique serial number has been added before, then the cloud-based platform 104 may provide a CIK to the device in response to the activation request.

[00196] (D) Content, which may include files that can be posted for the client model with a file identifier, actual content, a description, and a timestamp.

Devices can then use the provisioning API to get content, look for updates, and decide to download the content. This may be used for tasks like updating firmware and applications in the field, and finding configuration files for devices to download.

[00197] (E) Groups that may be created that specify what serial numbers can access what content. This may be used for controlling access to certain content, perhaps if DOs have a license for more advanced features of a device.

[00198] The following procedures may be performed by the vendor to make and update a client model: (A) vendor registers a vendor name; (B) vendor configures a client to be used as a clone for the model; (C) vendor creates a model under vendor name based on client clone; (D) vendor configures downloads for the model; (E) vendor adds one or more serial numbers to the model serial number pool; and (F) vendor updates model downloads, serial numbers, and/or other details.

Webpages and Web portals

[00199] It also is contemplated that the cloud-based platform 104 may include components and functionality for providing one or more web portals. A web portal may include a web application providing a graphical interface by which to communicate with deployed devices and interact with data. The web portal may allow developers to connect and manage products and applications using web service APIs. Devices may become a virtual client the cloud-based platform 104, in a hierarchy of other cloud clients representing devices, users, and account owners. The cloud-based platform 104 may handle many concurrent requests from cloud clients (devices) including devices talking to its APIs, web portals, and other applications. The cloud- based platform 104 may use identifiers to authenticate connections and accept requests like read, write, edit, create, etc.

[00200] A user may log into a web portal using the user's email address and password, or other identifying information. There may be different types of users. The vendor may be the user who initially created the portal. The vendor may have access to everything in the portal. Managers may have all of the same functionality as the vendor, but may not be able to change resource limits and add resources. When a user is specified as a viewer, a dashboard may be selected in addition to adding the user as this role type. When logging in, the user may only see dashboards to which the user was granted access. The user may not see the same information or menus as the owner or the managers. Email and phone information of the viewer may be available for use in sending alerts. A user specified as a 'contact' may have their email and phone information available for sending alerts, but may have no view or manage access. New users may be signed up for the web portal. One way is for the user to directly sign up for an account. Additionally or alternatively, user log-ins may be added to the portal by an administrator. For example, a manager of the web portal may add a user log-in by clicking on an admin link 356 on a manage menu 358 on a left side of the screen, as shown in FIG. 38. The manager may invite a user with a specific role 360 selected for the user. The address 362 of the user may be entered and a role selected. To add new users, there must be resources available. The portal resource summary 364, which may be indicative of the availability of resources for new users, may be found on the same page. When a user in invited, they may receive an email letting them know they have been granted access, and if they do not have a log-in already, they may be asked to create their user account. Adding more resources for new users may entail navigating to a billing page (FIG. 39) and purchasing add-ons to increase the portal's user resource count. [00201 ] The cloud-based platform 104 also may include components and functionality to display one or more dashboards. A dashboard may include a one- page webpage that may contain one or more widgets containing information, typically from the cloud-based platform. A widget may be, for example, a list of data sources and values, a graph showing data sources, or a simple text dialog box. A dashboard may be linked to a portal account, and all devices, events, and data associated with the port may be available for visualization in the dashboard. An exemplary dashboard 366 is shown in FIG. 40. A portal may display multiple dashboards depending on the account level. One dashboard may be set as the home page, which may be the landing page when logging in. Dashboards can be shared with other account users depending on the account level, and all dashboards that have a public URL may be available to be shared (see FIG. 41 ).

[00202] One or more widgets may be viewed on the dashboard. These may include pre-defined widgets that may be available in portals, including: (A) a bar chart widget for averaging the data into bins of a specified window, and plotting each average as a bar on a bar chart; (B) a big number widget for taking a single data source and printing its latest value in large format; (C) a device list widget for listing all devices from a portal, including the current active state and event for each; (D) a gauge widget for showing the value of a data source on a configurable gauge; (E) a JSON viewer widget for showing editable JSON strings in a nested view, used for editing configurations and metadata; (F) a line graph widget for generating line graphs of data sources; (G) a tabular report widget for showing a report of past data or events; and (H) a text box widget for displaying a box in which to input text.

[00203] One or more customizable widgets may be available in portals. These widgets may allow visualization of data on a dashboard by using, for example, customizable JavaScript. Custom widgets may be used for the following: (A) manual data entry (FIG. 42); and (B) EMD configuration settings, where configuration parameters of EMDs may be set or updated. Multi-page widgets may be provided for different configurations (e.g., sensor and cloud configurations) (FIG. 43). [00204] The cloud-based platform 104 also may include components and functionality to manage aspects of the cloud-based platform 104. For example, the cloud-based platform 104 may provide select users with access to a menu 368 that lists resources of the cloud-based platform 104 (FIG. 44). The items included in the menu 368 may be hidden for non-admin or otherwise unauthorized users. By selecting devices 370 from the menu 368, a list of all activated devices may be displayed to, for example, their NO (FIG. 45). Selecting a listed device may cause a window to appear that shows device information (e.g., data sources, cloud metadata, and settings) (FIG. 46). Devices may be deleted from the cloud-based platform 104 through the menu 368, and thus, access to the menu 368 may be restricted to authorized users.

[00205] By selecting data 372 from the menu 368, a list of data sources of devices may appear (FIG. 47). By selecting a data source 374, a data information window 376 may appear (FIG. 48). By selecting events 377 from the menu 368, a list of available events and alarms (dispatches) may appear. Some exemplary types of events include: (A) simple events (FIG. 49); (B) timeout events (FIG. 50); (C) duration events (FIG. 51 ); and (D) count events (FIG. 52). For an alarm (dispatch), an event may often remain in an alert state until a problem is resolved. In this state, the cloud- based platform 104 may continue to send alerts on specified intervals until the data returns to a non-alert level. The alerts may be sent to a specific recipient by email or SMS. The alerts may, for example, be used to prompt the DO (by email or SMS) about maintenance or calibration needs associated with the devices.

[00206] By selecting dashboards 378 from the menu 368, a list of available dashboards (not shown) may be displayed. By selecting scripts 380 from the menu 368, a list of available scripts (not shown) may be displayed. Script applications may have access to all of a cloud client's resources for creating more advanced conditional rules or creating algorithms to process data. These scripts may, for example, have access to the cloud client's variables and functions, and/or may have the ability to call dispatches. By selecting admin 382 from the menu 368, a window 384 that allows adding users, checking resource limits, and changing the name for portals, may be displayed (FIG. 38).

[00207] The cloud-based platform 104 also may include components and functionality for providing an admin interface 386, shown in FIG. 53, having a list of menu options 388 on the left-hand side. Selecting users 390, portals 392, devices 394, and billing 396 may open options for managing those aspects of the cloud-based platform 104. Selecting domain setup 398 may display tables, menus, and/or options for: (A) configuration (e.g., landing and login pages, footer links, manage menu, user terms and privacy policy, email notifications, signup and account page configuration, pricing page plans, and pricing page Ul; (B) dashboard settings; (C) widgets (e.g., adding custom widgets, editing widgets, removing widgets); and (D) theme (e.g., edit the theme to give it a desired look and feel).

[00208] From the admin interface 386, selecting client models 400 may display tables, menus, and/or options for: (A) managing models (e.g., adding client models); (B) serial numbers (e.g., adding valid serial numbers of devices based, for example, on a set range of serial numbers. There may be a list of used serial numbers and their status (used/not used/activated) (FIG. 54). Groups can be created that specify what serial numbers can access what content. This may be useful for controlling access to certain content, perhaps if some DOs have a license for more advanced features of devices than other DOs.

[00209] A device that has been activated as part of a client model may be able to download authorized content from the client model. This feature may be used for providing new firmware to devices in the field (e.g. in-field updates), and for providing new media content to devices (e.g. new images for advertisement content). Some of the available functions may include: (A) get content list (e.g., provide a list of available content); (B) get content info (e.g., get details of each content item

(timestamp, description, etc.)); and (C) get content (e.g., get actual content). A device may need to have prior knowledge of the naming scheme and format of the content available for download. For example, a device may use content having IDs starting with "firmware" for new firmware files. Client model content may be managed by the vendor who owns the client model. They may be responsible for maintaining the content available, as well as for managing access rights to the content.

[00210] FIG. 55 is a depiction of an exemplary webpage 402 of a web portal of the cloud-based platform 104. The webpage 402 may be included as data and/or intelligence services offered by the cloud-based platform provider. The information displayed on the webpage 402 (including, for example, any suitable text, numerical values, graphics, and/or pictures or video feeds) may be obtained from one or more EMDs operatively linked to the cloud-based platform 104. Each of the EMDs may provide all of the displayed information, or may provide one or more elements of the displayed information. The webpage 402 may be accessible via any suitable electronic device, including, for example, any type of mobile phone, personal data assistant ("PDA"), tablet, personal computer ("PC"), laptop, electronic kiosk, or the like. FIG. 56 depicts a feature of the cloud-based platform 104 where webpage and/or web portal data may be processed and presented in different ways for different end users. In this example, the left side of the image depicts data/views presented to, for example, a city official, while the right side of the image depicts data/views presented to the general public.

[0021 1 ] Custom webpages may be built into the Wi-Fi modules of the EMDs. The webpages may be displayed from webservers to provide a user interface with DOs. The user interface may facilitate: (A) Wi-Fi network configuration; (B) EMD registration to the cloud-based platform; (C) informing EMDs about new sensor connections and I/O interface type (SDI-12, RS-232, RS-485); (D) providing cloud connection feedback (e.g., connection status, data transmission status); (E) providing means for factory reset; (F) testing sensor measurements; (G) debugging; and (H) indicating Wi-Fi signal strength.

[00212] A local IP address may be used to communicate with the EMDs. Authentication may be required, which may include a prompt request for user ID and password information. After configuring the Wi-Fi network, an EMD may be registered to the cloud-based platform 104. The following information may be presented for registration: (A) network ID (e.g., client model name that the vendor provides for the NO; the NO may provide this ID for all Dos); (B) site name/site number (e.g., the NO may assign a name/number for the site in which an EMD is installed; this

name/number may be used in the cloud-based platform as the name of different EMDs; (C) location (e.g., the location may be used as metadata for each EMD. After entering the above information, the EMD may register (e.g., enable and activate) itself to the cloud-based platform. A confirmation page may be shown after successful registration.

[00213] It also is contemplated that, because of power constraints of EMDs operating in low power mode (or even medium power mode, in some

instances), automatic sensor detection may not be feasible. In such instances, DOs may inform the EMDs about the connection of new sensors. One of the webpages may include the following sections: (A) sensor interface type (SDI-12, RS-232, RS- 485); (B) sensor type (for RS-232 and RS-485 interfaces); and (C) an add sensor button.

[00214] One of the webpages may provide cloud connection feedback for the Dos, including: (A) cloud connection status; and (B) data transmission status. The webpage also may provide a signal strength indicator. The indicator may display bars as a strength indicator of the signal received from a router, hotspot, or other wireless AP.

EIS Bridge Methodology

[00215] FIG. 57 shows steps performed from end-to-end, using the EIS 100, for providing environmental intelligence. In step 1 (ref. 404), an EMD, via one or more connected sensors (such as an SS), may take an environmental measurement. This may produce raw sensor data. Each EMD can have multiple sensors attached at the same time, and thus, may take multiple, different measurements simultaneously. The sensors may cover a multitude of sensor types. The raw data may be factors used in subsequent steps. In step 2 (ref. 406), each piece of measurement data that is collected may be a factor fed into one or more algorithms. The algorithms may take into account each singular factor of input, and/or may combine different factors together. The algorithms also may apply scientific logic and formulations (e.g., rule- based logic) to determine one or more results. Additionally or alternatively, the algorithms may take past historical data into account, and may analyze such data for any directional trends that may or may not be present. This analysis may be applied to the raw data to identify similarities, differences, and/or trends. Pre-defined and/or custom business logic rules and thresholds also may be applied to highlight certain key value points. In step 3 (ref. 408), based on the algorithmic outputs and business rules/logic, an indicator may be derived that may denote, for example, a probability of a weather event "trend" either happening or not happening. This step may entail having a predictive analytics engine identify positive trend indicators, neutral trend indicators, and/or negative trend indicators. In step 4 (ref. 410), the cloud-based platform 104 may, based on the data analytics and algorithm outputs, then provide some level of suggested decision guidance/actionable insight to an end-user of the EIS 100. This may include sending alert notifications to the end-user. Additionally or alternatively, the end-user may be provided with a probability of a weather even occurring, its severity, etc., and/or an insight that the end-user may utilize to plan action based on the data. In one exemplary application, data from each of the steps may be used in any of the downstream steps. The inclusion and use of one or more of the components and functionalities above may enhance the performance of these steps.

[00216] In one example, the EMD may take measurements for air temperature, surface temperature, and calculated dew point to determine the likeliness and state of frost formation on roads. Through the data analytics function, the predictive analytics engine may output event indicators 412, 414, and/or 416. This may be presented to the end user with the decision guidance/actionable insight explanation, or may be presented on its own. Exemplary algorithms for generating event indicators 412, 414, and 416 are shown in FIGS. 58A-58C. One or more of the event indicators 412, 414, and 416, may be communicated to the end user at step 5 (ref. 418)of the depicted process in FIG. 59 and/or at step 3 (ref. 420) in FIG. 60. QA/QC

[00217] In-field data measurements may experience measurement anomalies. The anomalies may be the result of scenarios like (but not necessarily limited to): (A) erratic sensor malfunctions; (B) uncalibrated sensors; (C) missing measurements (data gaps); (D) incorrect time stamps; (E) manual data measurement updates by measurement experts or field teams; and/or (F) data spikes/data troughs. To resolve and address the above, the data collection architecture of the EIS 100 may have built-in real-time and inline data QC/QA business rules that may automate the checking of data measurement points. Unlike offline or conventional arrangements, where raw data may be collected and stored in the field on a device and later manually transferred and manually processed, the EIS 100 may perform data QA/QC in realtime, with the data being in-line processed as it is read and measured by the EMD 1 14. An exemplary process 422 of inline data QA/QC is shown in FIG. 60. The process 422 may include three steps, including a step 424 of ingesting data in multiple formats, with examples of the ingested data shown; a step 426 of running one or more data validation algorithms and/or checking business rules, with examples of validation and checking processes shown; and the step 420 of generating alerts/notifications, with considerations for the alerts/notifications being shown.

[00218] Measurement data as measured by the EMD 1 14 may be validated or compared to either pre-defined rules that may include, but should not be limited to: (A) a predefined range of expected data, with any data above or below considered an outlier that may be flagged, (e.g., for air temperature measurements, a data point measurement of 600 degrees Celsius may be flagged as possible error); (B) where there are data gaps or missing measurements, EMD algorithms may flag the timeframes or records where expected measurements cannot be found; (C) customers may have their own custom definitions and thresholds so that the EMD 1 14 may flag, reject, or accept measurement data at the front end of the process (e.g., ignore wind speed measurement data where it is slower than 2 KM/hr).

[00219] Expanding on the step 3 of FIG. 60, an example of geospatial data reference checking is shown in FIG. 61 . FIG. 61 shows various sources 430, 432, and 434 of third party data (e.g., from one or more EMDs, sensors, or stations), located in different vicinities, being used to check data gathered by the EMD 1 14 to, for example, gauge the quality of the data provided by the EMD 1 14. The vicinities may be, for example, as geo-relevant sites with similar characteristics, such as proximity, altitude, and/or land use. This may allow validation that measurements at the sites are comparable and thus of expected quality (e.g., no sensor defect or site based bias).

[00220] Additionally or alternatively, the cloud-based platform 104 may collect both measurement and metadata from one or more field sites. In use, the EMD 1 14 may provide measurement data. Measurement data may be the magnitude of a quantity relative to an agreed standard. Measurement of any quantity may involve comparison with some precisely defined unit value of the quantity. In the EIS 100, standard units of measure may be identified and defined as accurately as possible. The utility of measurements may be enhanced when they are used not only as standalone values, but rather, are used in conjunction with other data. One example of other data is measurement metadata, which may include descriptive data that provides information about the measurement data. The measurement metadata described herein may encompass metadata as defined by the World Meteorological Organization (WMO). Additionally or alternatively, the measurement metadata may provide context for a specific piece of measurement data. For example, the

measurement metadata may include information such as the SS and/or base make and model, calibration information, location information, etc. FIG. 62 includes a table that provides examples of what metadata may encompass in the context of the EIS 100, and in particular, the EMD 1 14. In one exemplary process, a flag may be set in the cloud-based platform 104 for sensor maintenance and/or calibration, the flag communicating a need for sending an alert (e.g., email, SMS, etc.) for the NO or the DO to perform maintenance and/or calibration of one or more of the EMDs in the EIS 100. The flag may be set based, for example, on the metadata information in the leftmost column of the table in FIG. 62. For example, if a data value in the metadata information exceeds or falls below a predetermined threshold, the flag may be set. The metadata and configuration parameters may be stored as a string in the platform, with XML and/or JSON formats being used for this purpose. In one example, the metadata and configuration parameters may only include text-based data and/or may be transmitted less frequently, to reduce the overall volume of data transmission, due to power consumption restrictions associated with or implemented by the EMD 1 14.

[00221 ] The cloud-based platform 104 may run initial QA/QC routines on the incoming data (e.g., measurements and metadata), preparing it for both display and/or distribution. In one example, sensor metadata may be used to generate calibration notices and/or track an EMD as it is used throughout the network. For example, metadata would include some or all of the calibration history for a given EMD, as well as the EMD manufacturer's suggested calibration timeline (intervals). Knowing the last calibration date for a given EMD and its suggested timeline, the cloud-based platform 104 can calculate the next calibration date and provide a reminder when it is due. Additionally or alternatively, tracking the history of activities (installation, maintenance and calibration, removal, and/or redeployment) an EMD has been through over its lifetime allows tracking of how EMDs are used throughout a network.

[00222] Software may provide data and reports (text and/or graphical) to facilitate the client decision-making process. The cloud-based platform may provide archival of both the data and metadata. This automated QA/QC process, which may be supplemented by human review of the data, can also be combined with system processes and workflows to automatically initiate actions to correct data issues including triggering calibration and maintenance activities in the field. Learning from this process may also allow the system to continuously improve the preventive maintenance schedules. This may be facilitated due to the full integration of all parts of the EIS 100, from hardware in the field to the cloud-based platform x, with enterprise system functionalities. FIG. 63 shows the EMD 1 14 and various forms of metadata that may be gathered by the cloud-based platform 104 for the EMD 1 14. FIG. 64 exemplifies how the cloud-based platform x may manage EMDs and measurements, as well as the configuration, maintenance, and calibration history over their operational lifetime. FIG. 64 shows that the EMD-related information may be integrated with other aspects of the cloud-based platform 104.

[00223] Using the metadata from the EMD 1 14, and any other data associated with communications between the EMD 1 14 and the cloud-based platform 104, the cloud-based platform 104 may have the ability to monitor one or more characteristics of the EMD 1 14 for at least a portion of a lifecycle of the environmental measurement device. The one or more characteristics may include, for example, geographic location of the EMD 1 14, maintenance events undergone by the EMD 1 14, calibration events performed on the EMD 1 14, and any of the characteristics identified in the blocks shown in FIGS. 63 and 64. The characteristics may be expressed in metadata provided by the EMD 1 14.

[00224] In one example, the cloud-based platform 104 is configured to monitor the EMD 1 14 for the entire lifecycle of the EMD 1 14, the entire lifecycle covering a time period from initial introduction of the EMD 1 14 to the EIS 100 (e.g., initial placement of the base and/or sensor of the EMD in communication with the cloud-based platform 104) to final disposition of the EMD 1 14 (e.g., when the EMD 1 14 is decommissioned or otherwise taken out of communication with the cloud-based platform 104 or the EIS 100 in general). It should be understood that during the entire monitored lifecycle, the EMD 1 14 may be placed in communication and taken out of communication with the cloud-based platform multiple times. The full history of the EMD 1 14 may be displayed to a user. For example, a time-based visual, similar to the graph in FIG. 31 , may be displayed, and may show data over time on one or more of the monitored characteristics.

[00225] The information/data described above may be used to generate an alert indicating that calibration, repair, or replacement of the EMD 1 14 may be required. Additionally or alternatively, machine Intelligence analysis of the EMD 1 14 may be used to detect when calibration, repair, or replacement is required.

EIS Diagnostics

[00226] An additional or alternative approach to improving performance and measurement quality is shown in FIG. 65. With this approach, internal statistics may be kept throughout software modules of the EIS 100, and may be used to determine the health and operations of firmware modules of the EMD, to perform progressively aggressive "recoverable actions." These actions have the goal of maintaining independently operable EMDs. Since a priority may be to protect the integrity of measurement data on the EMDs, the programmable logic may ensure survivable operations to maintain data integrity. In one example, the availability of power and/or voltage may drive the actions. In a first scenario 436, when the EMD is operating with a reliable power source, and the voltage is within normal power parameters of the EMD, the firmware service returns a "normal" health status. The service may authorize continuous power flow to all EMD device features and core functions so everything can operate as expected. In a second scenario 438, when the EMD is operating with a reliable power source and the voltage drop has breached the first pre-determined "warning" level as required by the EMD, the firmware service may return a "warning" health status, and pre-determined actions may be initiated to begin a first round of power conservation. The service may authorize the cut-off of power flow to lower priority features as a first step, so higher priority features and critical core functions can continue to operate as expected. In a third scenario 440, when the EMD is operating with a reliable power source and the voltage drop has breached the second or third pre-defined "critical" level as required by the EMD, the firmware service may return a "critical" health status, and additional pre-determined actions may be initiated to begin the second round of more aggressive power conservation methods. The service may authorize additional cut-offs for power flow to all "features" as well as more aggressive power restrictions to critical core functions that only get power when needed (rather than continuous power) so that core operations can continue as expected.

[00227] An additional or alternative approach is shown in FIG. 66. This approach may be similar to the one in FIG. 65, except the number of errors detected on the EMD, rather than power and/or voltage, may drive the actions. In a first scenario 442, when the EMD is operating with a reliable power source and any errors being generated are below a minimum threshold of error rates for the EMD, the firmware service may return a "normal" health status. The service may authorize continuous power flow to all EMD device features, core functions, and active sensors so everything can operate as expected. In a second scenario 444, when the EMD is operating with a reliable power source and any errors being generated are above a first level of "warning" thresholds, but under a second level of thresholds, the service may return a "warning" health status, and predetermined actions may be initiated to ensure that the error log does not overwhelm the data transfer buffer and fill it with errors, and thus put back pressure on valid measurement data that needs to be sent out to the cloud-based platform 104. Actions that the service may authorize can include cutting off power flow to sources that are generating excessive errors, or features that are generating excessive error logs. As a first step, less aggressive management may be attempted, such as delaying status reporting of the source of the errors to throttle the error reports, or rationing power delivery to a sensor that may be generating the error, so as to give valid measurement data a chance to be transmitted back to the cloud-based platform 104. In the third scenario 445, when the EMD is operating with a reliable power source and any errors being generated are above the second and third levels of "critical" thresholds, the service may return a "critical" health status, and additional predetermined actions may be initiated to begin a second round of more aggressive excessive error log bypass measures, so that the transmission of valid measurement data to the cloud-based platform 104 may continue. The actions that the service may authorize may include a total cut-off of power flow to sources that may be generating excessive errors, or features and core functions that may be generating excessive error logs. This may clear a clear path so that valid

measurement data may be transferred to the cloud-based platform 104.

[00228] An additional or alternative approach to improving performance and measurement quality is depicted in FIGS. 67 and 68. Remote firmware updates of the EMDs may be performed through a mechanism known as over-the-air (OTA) updates. When EMDs are connected to the Internet, the may access the cloud-based platform 104, and may check in with a central management database on a defined schedule to determine whether they are operating on the latest version of a firmware release. If there is a newer firmware release available, the EMD may attempt to download the firmware. Once the firmware has been downloaded successfully and checked for data integrity, the firmware upgrade process may begin. In the cases where connectivity may be weak, intermittent, or otherwise compromised, the EMD may attempt to try its dual modes of connectivity to connect to the central cloud-based platform 104. The first option may be via Wi-Fi connectivity, and the second may be to utilize the cellular network. Architecture for this is shown in FIG. 67.

[00229] Firmware updating via the OTA method is an important function for the EMD. As the EMD has been designed with dual connectivity options, and in conjunction with the integrity check after download, if a download fails, the EMD will reboot and continue to run and load successfully in a last known good configuration (FIG. 68). Additionally, if the first attempt for the firmware download was utilized on one connection, if that connection becomes unavailable or unstable, the EMD may alternatively use the second method to connect back to the cloud-based platform 104. The existing firmware file that is on the EMD may be overwritten after a successful firmware update, but since the firmware boot loader is non-volatile, it may be recoverable even in the event that a catastrophic failure happens during a firmware file update. The core base operational functions may reside in the firmware boot load function, including all connectivity functions. In the case of a failed firmware file update, the resolution may be to download and apply a new and remediated version of the firmware file.

[00230] A network to firmware updater process is shown in FIG. 69. The process may start with installing a callback to the network (step 446), then waiting for the callback function to be called. Whenever the callback function is called (step 448), the firmware version from the cloud may be checked (step 449) using a function provided by the network. If the version is same version, there is a wait for the next call (step 450). If the version is different (step 451 ), then the version is requested (step 452) using a function provided by the network, and the version is written to an external flash (step 453). Once the transfer is done (step 454), the system is restarted (step 456) so that the firmware upgrade can be applied. [00231 ] A file client in the EMD may be responsible for obtaining and updating local files by talking to a portal file server. This is exemplified in the communication diagram of FIG. 70. The file client may register (step 458) with network services for a callback when a connection is made. Once the connection is made (step 460), a list of tokens may be sent to the file server (step 462). The file server may reply with file names which also have the version as part of the name (step 464). The file client may check the local file system to see if it has those files (step 466). If it does not, then it may request them (step 468). Once the file client has all the local files, it may tell network services that it is done. FIG. 71 shows a flow diagram of a process similar to the one shown in FIG. 70.

[00232] The EIS 100 may include a centralized cloud catalogue 470 for sensors, as shown in FIG. 72. When an EMD comes online, it may connect to the cloud-based platform 104 and may begin registration processes. The cloud-based platform 104 may acknowledge the registration request, process the metadata, and query the catalog for the EMD device configuration profile. The EMD configuration file may be pushed down to the EMD to complete registration and begin full operations in the field. The configuration file may include one or more of: (A) measure rate and/or intervals; (B) sensor trigger commands; (C) processing type (sample, min, max, avg.); (D) output interval; (E) power management; (F) communications rate; and/or (G) diagnostics type.

[00233] Each EMD may be registered to a client model or application type. When the EMD comes online, it may connect to the cloud-based platform 104 and obtains its operational characteristics associated with the client model. Some configuration parameters may be independent of the sensors. These include items such as: (A) connection interval with the cloud (the EMD initiates communications with the cloud); (B) diagnostic levels; (C) measurement parameters associated with physical health monitoring, such as: (1 ) battery voltage; (2) solar panel voltage; (3) internal temperature and relative humidity; and (D) power management levels associated with the EMD and communication. [00234] When a sensor is connected to the EMD, the EMD may automatically detects the connection. One means of detection is where a current draw may be detected on the power output to the sensor, or a sensor detect line connection is sensed (ground). After a connection is detected, the EMD may scan for the SDI-12 address of the connected device. Once the address is identified, the SDI-12

identification command may be sent to the sensor, which may then be recorded by the EMD and then transmitted to the cloud-based platform. The cloud-based platform then may identify the configuration file associated with the results of the identification command for the EMD client model. The configuration file associated with the sensor may be unique for each client model. Once the appropriate configuration file is identified by the cloud-based platform, the EMD may then download the configuration file and begin measuring, collecting, processing, and transmitting data according to the configuration file.

[00235] An EMD may connect periodically to one or more portals of the cloud-based platform to check the download files for: (A) configurations; (B) EMD firmware; (C) Wi-Fi firmware; (D) cell modem firmware; and/or (5) SSL certificates. The request/response dialog is shown in FIG. 73. The EMD may request the current version of one of the files listed above using a token to represent the file. When it gets the version, it may check it against its local copy. If it is different, then it may download the file and store it locally. Part of the request version may include the EMD's serial number. Currently, file versions may be checked every time the EMD connects to the portal. For frequent data pushes, this might add extra overhead. To reduce overhead, the check interval may be set to check, at most, once every designated time period. This way, frequent data pushes may not get the extra overhead of file checks. For each check, the image files may be checked, and any connected sensors may be checked. Since all the queries may be contained in one HTTP request, there may not be much difference with the number of items checked for.

[00236] When the EMD makes a query about a file, the query may be mapped to the file name. The portal may first check to see if it can be mapped by serial number to a specific directory. If no serial number directory exists, then it may use the default directory and return the file name for the query. The mapping is exemplified by FIG. 74. Each file name may be preceded with its path. This full path and file name may be used subsequently to download a file. The path may either be in the default directory or with a specific serial number.

[00237] A remote command line interface and access to EMDs may be available anywhere where there is access to an IP transport network. Remote console access to the EMD may allow for: (A) low level access to perform diagnostics functions; (B) elevated access to troubleshoot and remediate potential EMD issues; (C) ability to access the EMD console from anywhere with an IP connection; (D) transfer of data to and from the EMD device; and (E) ability to remotely view metrics on the EMD device. In one example, small frame protocol (SFP) over UDS may provide remote console access to the command line interface. This is shown in FIG. 75.

[00238] By leveraging the first stage connection to the EMD from FIG. 75, it may be possible to connect directly to the console of the sensor of the EMD. This is shown in FIG. 76. The linkage provided by the remote command line interface between aspects of a base 1 12, 152, a file system 472 (which may include a database on the cloud-based platform 104), and a sensor 474, is shown in FIG. 77. Remote console access to the end sensor allows for: (A) low level access to perform diagnostics functions; (B) elevated access to troubleshoot and remediate potential sensor level issues; (C) ability to access the sensor console from anywhere with an IP connection; (D) transfer of data to and from the sensor device; and (E) ability to remotely view metrics and measurement on the end sensor.

Manufacturing and Testing

[00239] After manufacturing an EMD, the vendor may test it for automatic configuration capability, measurement quality, and cloud connectivity. Testing may be performed using the Wi-Fi connection. Exemplary testing steps may include: (A) assigning a network ID for testing the EMD; (B) setting sensor and base configurations in the cloud-based platform; (C) having the EMD communicate with a smart device using Wi-Fi Direct to configure the Wi-Fi network configuration for communication to a wireless LAN; (D) communicating with the built-in webpage of the EMD using the smart device; (E) registering the EMD to the cloud-based platform; (F) checking whether the EMD is listed in the device list of the cloud-based platform as well as the database of the web server application; (G) connecting the sensor to the base and checking the automatic configuration capability (e.g., sensor detection and

downloading of configurations from the cloud-based platform); (H) performing a measurement with the EMD and sending data to the cloud-based platform; (I) verifying data in the cloud-based platform to check the cloud connectivity, EMD functionality, and sensor performance; (J) disabling and removing the EMD from the cloud-based platform and factory resetting the EMD; and (K) shipping the EMD to the customer.

[00240] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.