[go: up one dir, main page]

WO2018049527A1 - Systèmes et procédés associés d'intelligence environnementale - Google Patents

Systèmes et procédés associés d'intelligence environnementale Download PDF

Info

Publication number
WO2018049527A1
WO2018049527A1 PCT/CA2017/051085 CA2017051085W WO2018049527A1 WO 2018049527 A1 WO2018049527 A1 WO 2018049527A1 CA 2017051085 W CA2017051085 W CA 2017051085W WO 2018049527 A1 WO2018049527 A1 WO 2018049527A1
Authority
WO
WIPO (PCT)
Prior art keywords
environmental
measurement device
data
environmental measurement
online platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CA2017/051085
Other languages
English (en)
Inventor
Brian Day
Carl DE LEUW
Glenn BOSCH
Jules Paquette
Stanford HSU
James ROGOZA
David KUSHNIR
Robert Chapman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Campbell Scientific Canada Corp
Original Assignee
Campbell Scientific Canada Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Campbell Scientific Canada Corp filed Critical Campbell Scientific Canada Corp
Publication of WO2018049527A1 publication Critical patent/WO2018049527A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01W—METEOROLOGY
    • G01W1/00—Meteorology
    • G01W1/10—Devices for predicting weather conditions
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01W—METEOROLOGY
    • G01W1/00—Meteorology
    • G01W1/02—Instruments for indicating weather conditions by measuring two or more variables, e.g. humidity, pressure, temperature, cloud cover or wind speed
    • G01W1/04—Instruments for indicating weather conditions by measuring two or more variables, e.g. humidity, pressure, temperature, cloud cover or wind speed giving only separate indications of the variables measured
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01W—METEOROLOGY
    • G01W1/00—Meteorology
    • G01W2001/006—Main server receiving weather information from several sub-stations

Definitions

  • 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.
  • AWS scientific grade automatic weather systems
  • 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.
  • dataloggers 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.
  • 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.
  • 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.
  • 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
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • an environmental intelligence system may include an environmental measurement device configured to generate measurement data indicative of one or more characteristics of an
  • 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
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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.
  • 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.
  • 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.
  • a system for providing environmental intelligence may include an environmental measurement device configured to generate measurement data indicative of one or more
  • 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
  • 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.
  • FIG. 1 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure
  • FIG. 2 is another schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure
  • FIG. 3 is another schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIGS. 4 and 5 show components of, and processes related to, a current sense circuit, in accordance with aspects of the present disclosure
  • FIG. 6 is a perspective view of an environmental measurement device, in accordance with aspects of the present disclosure.
  • 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
  • FIGS. 8 and 9 are tables showing Wi-Fi and power features, , in accordance with aspects of the present disclosure.
  • FIG. 10 is a schematic illustration of a base of an environmental measurement device, in accordance with aspects of the present disclosure.
  • 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;
  • 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
  • FIG. 14 is a circuit diagram of the multi-protocol handling capability of FIG. 13, in accordance with aspects of the present disclosure
  • FIG. 15 is a schematic illustration of time-related aspects of an environmental measurement device, in accordance with aspects of the present disclosure.
  • FIGS. 16A and 16B are schematic illustrations of connector aspects of an environmental measurement device, in accordance with aspects of the present disclosure.
  • FIG. 17 is a circuit diagram of the connector aspects of FIGS. 16A and 16B, in accordance with aspects of the present disclosure.
  • 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.
  • FIG. 19 is a circuit diagram for an onboard sensor of an environmental measurement device, in accordance with aspects of the present disclosure.
  • 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
  • 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
  • FIGS. 22-24 are perspective views of a base, bracket, and pole assembly, in accordance with aspects of the present disclosure.
  • 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;
  • 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;
  • 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
  • FIGS. 31 -33 are exemplary webpages for displaying data from an environmental intelligence system, in accordance with aspects of the present disclosure
  • FIG. 34 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG.35 is a schematic illustration of an environmental intelligence system, in accordance with aspects of the present disclosure.
  • 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
  • FIG. 37 is a schematic illustration of a process for registering a device, in accordance with aspects of the present disclosure.
  • FIG. 38 is an screenshot of a webpage for account management in environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG. 39 is a screenshot of a webpage for purchasing resources in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG. 40 is a screenshot of a webpage showing dashboards in an environmental intelligence system, in accordance with aspects of the present disclosure
  • 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
  • FIG. 42 is a manual data entry widget of an environmental intelligence system, in accordance with aspects of the present disclosure
  • FIG. 43 shows a multi-page display for a widget of an environmental intelligence system, in accordance with aspects of the present disclosure
  • 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
  • FIG. 45 is a display listing devices in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG. 46 is a display showing device information in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG. 47 is a display showing data information in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • FIG. 48 is a data information window in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • 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
  • FIG. 53 is an administration or management webpage/interface for an environmental intelligence system, in accordance with aspects of the present disclosure.
  • 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
  • FIG. 55 is an exemplary webpage from a web portal of an environmental intelligence system, in accordance with aspects of the present disclosure
  • 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
  • FIG. 57 is a schematic illustration of steps performed using an environmental intelligence system, in accordance with aspects of the present disclosure
  • 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
  • FIG. 59 is a schematic illustration showing relationships between components in an environmental intelligence system, in accordance with aspects of the present disclosure.
  • 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
  • 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
  • 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
  • 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
  • FIG.64 is a schematic illustration showing ways an environmental measurement device can be managed, in accordance with aspects of the present disclosure.
  • 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
  • FIGS. 67 and 68 schematically illustrate over-the-air update capabilities of an environmental intelligence system, in accordance with aspects of the present disclosure
  • 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
  • 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
  • FIG. 71 is a flow diagram of the process of FIG. 70, in accordance with aspects of the present disclosure.
  • FIG.72 is a schematic illustration of a centralized sensor
  • FIG. 73 is a communication diagram of a dialog between an
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the EIS may include one or more new devices, including an
  • EMD environmental measurement device
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • 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).
  • 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.
  • 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 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;
  • E receives measured data from
  • 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.
  • FIG. 3 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.
  • the provider 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.
  • 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.
  • 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.
  • 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.
  • SS metadata may be forwarded when the SS 1 10 is connected to the base 1 12.
  • the metadata may be pushed to a central cloud location to be captured by software running in the cloud-based platform 104.
  • the EMD 1 14 may provide the metadata that may describe each individual data value.
  • Metadata may include "data about data,” and in some examples, may serve to qualify data.
  • 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
  • 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 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.
  • 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.
  • 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
  • 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.
  • DTE data terminal equipment
  • DCE data circuit-terminating equipment or data communication equipment
  • 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.
  • 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.
  • a base e.g., base 1 12
  • 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)
  • 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).
  • the I/O interface type SDI-12, RS-232, or RS-485.
  • (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.
  • the base 1 12 may recognize the sensor replacement by checking the serial number of the new SS.
  • the base 1 12 may be configured for use in the EIS 100.
  • 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).
  • the EMD's automatic configuration functionality may be enabled by current-sense technology.
  • 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).
  • a signal may be sent to a processor to denote that the SS 1 10 has been plugged in to a base.
  • 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.
  • a signal may be sent to a processor (e.g.., in the EMD 1 14) to denote that no sensor has been plugged in.
  • Provisions may be made for making the EIS 100 compatible with sensors that may not be automatic configuration compliant.
  • 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.
  • the cloud-based platform 104 may be designed and built with the ability to import data from any source.
  • some existing data acquisition systems 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.
  • 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.
  • 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.
  • any suitable controller/processor element e.g. the "processor” shown in FIG. 7
  • 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
  • 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.
  • IP International Protection
  • 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.
  • 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.
  • 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.
  • the base 1 12 may include two I/O connections or ports (not shown) configurable to SDI-12, RS-232, and/or RS-485.
  • the base 1 12 may include an
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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:
  • (B) Low power consumption e.g., one or more low-power modes of operation.
  • Adaptive Wi-Fi 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.
  • 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.
  • 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).
  • 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.
  • a configuration webpage may be hosted by the Wi-Fi module to communicate with the Wi-Fi module for Wi-Fi network configuration.
  • Wi-Fi Direct or a mobile/portable AP capability of smart devices may be used to configure using a web browser.
  • Wi-Fi Direct may be used to transfer data from the EMD 1 14 to the cloud-based platform 104.
  • 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.
  • 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.
  • 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.).
  • 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.
  • Wi-Fi direct button enables the Wi-Fi Direct capability of the Wi-Fi module to work as the access point.
  • the EMD 1 14 may have three power modes: (1 ) Low Power Mode (LPM); (2) Medium Power Mode (MPM); (3) High Power Mode (HPM).
  • LPM Low Power Mode
  • MPM Medium Power Mode
  • HPPM High Power Mode
  • 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.
  • 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.
  • Wi-Fi retransmission/retry rate restrictions 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.
  • 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.
  • 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.
  • 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.
  • the charge status of the battery 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
  • 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.
  • the base 1 12 may operate in one of a plurality of power modes.
  • exemplary power modes e.g., low, medium, and high power modes
  • the power modes may, for example, affect the retransmission/retry parameters outlined in FIG. 8.
  • 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).
  • RTC real-time clock
  • UTC universal time coordinated
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • a feature for testing sensor measurements and cloud connectivity may be provided in the built-in webpage of the EMD 1 14.
  • the feature may include processes that may initiate measurement and cloud connection to immediately confirm operation of the EMD 1 14.
  • 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.
  • 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.
  • 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.
  • FIGS. 1 1 and 12 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.
  • 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
  • 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.
  • 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).
  • the networked time source 186 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • base 152 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.
  • 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.
  • UBA universal bracket assembly
  • 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).
  • the housing 206 may include a rectangular-shaped body 214.
  • a first side (not shown) of the body 214 may be configured to engage the post 202.
  • 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.
  • Recesses may be formed on the second side 216 of the body 214.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the enclosure bracket 212 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.
  • 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
  • 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.
  • FIG. 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
  • Communications between the EMD 1 14 and the cloud-based platform 104 may be managed by integration of one or many communication
  • 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.
  • 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.
  • the AP 1 16 may be a permanent AP (PAP), such as a wireless router.
  • PAP permanent AP
  • the AP 1 16 may provide permanent/continuous access to the Internet.
  • the owner of a smart device e.g., smart phone, 3G tablet, etc.
  • 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).
  • 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).
  • 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.
  • 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.
  • an optimal communications linkage e.g., fastest, least power-consuming, most reliable
  • 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).
  • FIG. 30 shows aspects of a bridge between the EMD 1 14 and a portal 348 for providing data services and intelligence to clients.
  • 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.
  • 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.
  • 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).
  • GIS geographic information system
  • 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.
  • the cloud-based platform 104 may include data integration and volume management components and functions.
  • 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).
  • 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.
  • 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.
  • 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 .
  • 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
  • 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).
  • 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
  • the current surface temperature, wind direction, and other conditions may be displayed, if available.
  • FIG. 32 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.).
  • 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.
  • 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).
  • 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,
  • 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).
  • server-based services 350 below the dashed line 352
  • application specific layer 354 above the dashed line 352
  • FIG. 36 provides further explanations of the depicted components and functions.
  • 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.
  • laaS infrastructure-as-a-service
  • PaaS platform-as-a-service
  • SaaS software-as-a-service
  • Providers of laaS may offer computers, including physical and/or virtual machines, and other resources.
  • 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.
  • SaaS 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.
  • 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.
  • 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.
  • 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
  • resources such as data, rules, scripts, and dispatches
  • RIDs resource Identifiers
  • CIKs Client Identifier Keys
  • metadata information such
  • 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.
  • 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)
  • API application program interface
  • GUI programming graphical user interface
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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
  • 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.
  • the GET method is used for reading from the cloud-based platform.
  • the most recent value from one or more data ports with the alias can be read.
  • the client e.g. device or portal
  • the client to read from may be identified by the CIK. If at least one alias is found and has data, data will be returned.
  • (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.
  • writes occur before reads.
  • 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.
  • the EMD 1 14 may communicate with the cloud-based platform 104 using HTTP protocol.
  • 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).
  • HTTPS may be used rather than standard HTTP protocol.
  • 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-
  • 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:
  • Vendor 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.
  • 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.
  • (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).
  • CIK authentication key
  • 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.
  • 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.
  • a new device e.g., an EMD
  • 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.
  • FIG. 37 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).
  • SN serial number
  • 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.
  • TTL time to live
  • 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
  • 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.
  • 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.
  • 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
  • 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:
  • 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.
  • 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.
  • the serial numbers can be the MAC addresses of the EMDs.
  • a device 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.
  • (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.
  • 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.
  • 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.
  • a user may log into a web portal using the user's email address and password, or other identifying information.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ).
  • 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.
  • pre-defined widgets that may be available in portals, including: (A)
  • 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).
  • 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.
  • 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.
  • a list of data sources of devices may appear (FIG. 47).
  • a data information window 376 may appear (FIG. 48).
  • events 377 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.
  • 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.
  • dashboards 378 By selecting dashboards 378 from the menu 368, a list of available dashboards (not shown) may be displayed.
  • 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.
  • a window 384 that allows adding users, checking resource limits, and changing the name for portals, may be displayed (FIG. 38).
  • 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).
  • 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
  • widgets e.g., adding custom widgets, editing widgets, removing widgets
  • theme e.g., edit the theme to give it a desired look and feel.
  • 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.
  • 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
  • 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.
  • 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.
  • PDA personal data assistant
  • PC personal computer
  • 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.
  • 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.
  • 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;
  • 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.
  • an EMD 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.
  • 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.
  • 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.
  • FIG. 57 shows steps performed from end-to-end, using the EIS 100, for providing environmental intelligence.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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).
  • pre-defined rules 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); (
  • 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).
  • the cloud-based platform 104 may collect both measurement and metadata from one or more field sites.
  • 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.
  • 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 WMO).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • sensor metadata may be used to generate calibration notices and/or track an EMD as it is used throughout the network.
  • 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.
  • 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. 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.
  • 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.
  • 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.
  • 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.
  • FIG. 65 An additional or alternative approach to improving performance and measurement quality is shown in FIG. 65.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 66 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIGS. 67 and 68 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.
  • OTA over-the-air
  • the EMDs 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.
  • 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.
  • Firmware updating via the OTA method is an important function for the EMD.
  • 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.
  • 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.
  • 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.
  • 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.
  • the EIS 100 may include a centralized cloud catalogue 470 for sensors, as shown in FIG. 72.
  • an EMD 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.
  • 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.
  • 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.
  • file versions may be checked every time the EMD connects to the portal. For frequent data pushes, this might add extra 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.
  • 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.
  • 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.
  • 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.
  • small frame protocol (SFP) over UDS may provide remote console access to the command line interface. This is shown in FIG. 75.
  • 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.
  • 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

Landscapes

  • Environmental & Geological Engineering (AREA)
  • Engineering & Computer Science (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Ecology (AREA)
  • Environmental Sciences (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)

Abstract

L'invention concerne un procédé d'intelligence environnementale pouvant consister à obtenir des données de mesure indiquant une ou plusieurs caractéristiques d'un environnement. Le procédé peut également consister à traiter les données de mesure par l'application d'un ou plusieurs algorithmes afin de produire des données traitées. Le procédé peut en outre consister à analyser les données de mesure et/ou les données traitées afin de produire des données analysées. Le procédé peut également consister à communiquer les données de mesure et/ou les données traitées et/ou les données analysées à un utilisateur.
PCT/CA2017/051085 2016-09-14 2017-09-14 Systèmes et procédés associés d'intelligence environnementale Ceased WO2018049527A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662394601P 2016-09-14 2016-09-14
US62/394,601 2016-09-14

Publications (1)

Publication Number Publication Date
WO2018049527A1 true WO2018049527A1 (fr) 2018-03-22

Family

ID=61618601

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2017/051085 Ceased WO2018049527A1 (fr) 2016-09-14 2017-09-14 Systèmes et procédés associés d'intelligence environnementale

Country Status (1)

Country Link
WO (1) WO2018049527A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109270597A (zh) * 2018-09-06 2019-01-25 东华大学 一种用于强对流天气预警的矿业安防节点
US20200162280A1 (en) * 2018-11-19 2020-05-21 Johnson Controls Technology Company Building system with performance identification through equipment exercising and entity relationships
US20210190516A1 (en) * 2019-12-23 2021-06-24 Robert Bosch Gmbh In-Vehicle Sensing Module for Monitoring a Vehicle
CN119835616A (zh) * 2025-01-20 2025-04-15 澳门理工大学 用于文化遗产保护的模块化环境监测方法、装置和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7486201B2 (en) * 2006-01-10 2009-02-03 Myweather, Llc Combined personalized traffic and weather report and alert system and method
US8325034B2 (en) * 2009-04-13 2012-12-04 Jason Lee Moore Weather alerts
USRE43903E1 (en) * 1997-02-13 2013-01-01 Richmond Ip Holdings, Llc Severe weather detector and alarm

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE43903E1 (en) * 1997-02-13 2013-01-01 Richmond Ip Holdings, Llc Severe weather detector and alarm
US7486201B2 (en) * 2006-01-10 2009-02-03 Myweather, Llc Combined personalized traffic and weather report and alert system and method
US8325034B2 (en) * 2009-04-13 2012-12-04 Jason Lee Moore Weather alerts

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109270597A (zh) * 2018-09-06 2019-01-25 东华大学 一种用于强对流天气预警的矿业安防节点
CN109270597B (zh) * 2018-09-06 2023-09-22 东华大学 一种用于强对流天气预警的矿业安防节点
US20200162280A1 (en) * 2018-11-19 2020-05-21 Johnson Controls Technology Company Building system with performance identification through equipment exercising and entity relationships
US20210190516A1 (en) * 2019-12-23 2021-06-24 Robert Bosch Gmbh In-Vehicle Sensing Module for Monitoring a Vehicle
US11776332B2 (en) * 2019-12-23 2023-10-03 Robert Bosch Gmbh In-vehicle sensing module for monitoring a vehicle
CN119835616A (zh) * 2025-01-20 2025-04-15 澳门理工大学 用于文化遗产保护的模块化环境监测方法、装置和系统

Similar Documents

Publication Publication Date Title
CN112202590B (zh) 规则驱动的软件部署代理
US9838762B2 (en) Telemetry system and apparatus
US20200067789A1 (en) Systems and methods for distributed systemic anticipatory industrial asset intelligence
US20230162123A1 (en) Devices, systems and methods for cost management and risk mitigation in power distribution systems
CN105706469B (zh) 管理机器对机器设备
US11445392B2 (en) Unified management and monitoring of IoT nodes with multiple network connections
US10180893B2 (en) System and method for providing additional functionality to developer side application in an integrated development environment
US20160050279A1 (en) METHOD FOR MANAGING IoT DEVICES AND ANALYZING SERVICE OF BIG DATA
US20130234863A1 (en) Method and apparatus for mobile metering
WO2018049527A1 (fr) Systèmes et procédés associés d'intelligence environnementale
US20160231372A1 (en) Wire Diagram Tagging System
CN103490941A (zh) 一种云计算环境中实时监控在线配置方法
US10289522B2 (en) Autonomous information technology diagnostic checks
Urtecho et al. Enhancing agriculture through IoT and blockchain: a VeChain-enhanced sustainable development approach for small-scale agricultural exploitations
Rayes et al. Iot services platform: Functions and requirements
GB2627056A (en) Systems, devices, and methods for tracking remote equipment location and utilization of computing devices
EP4520095A1 (fr) Dispositif de surveillance environnementale modulaire
KR101780393B1 (ko) 융합형 장비 관리 정보 제공 단말
Cluster Community Wiki Document on Best practices for sensor networks and sensor data management. Federation of Earth Science Information Partners
Pauli Open metering
AU2010206502B2 (en) Telemetry system and apparatus
CN115757030A (zh) 容器集群监控平台的监控方法、装置和计算机设备
Figura et al. ICST TransactionsPreprint

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17849968

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17849968

Country of ref document: EP

Kind code of ref document: A1