Expert Support Dedicated To You
Frequently Asked Questions
Device Cloud is a public cloud platform for device network management. It provides secure application messaging, data storage and device management for networks comprised of wired, cellular and satellite-connected devices.
Device Cloud offers customers centralized management of gateways and connected end-devices, ease of integration via APIs and Etherios Cloud Connector, elastic scalability that grows with the device network, commercial-grade reliability and industry-leading security policies.
Sometimes referred to as Machine-to-Machine (M2M), device networks enable both wired and wireless systems to communicate with other devices and applications across different network types. As an example, a device (such as a sensor or meter) captures an event (such as temperature, tank level, etc.) which is relayed through a network aggregation layer (wired, wireless or both) and infrastructure to an application (software program) that translates the captured event into meaningful information (for example, tanks need to be emptied or refilled).
Device Cloud is used across a wide range of industries and M2M solutions. Smart Energy, tank management, mobile asset management, medical and retail to name but a few. Smartlee™ (available free on both the iPhone and Android platforms) is an excellent example of a smart energy mobile application. With this application, a user can monitor home energy consumption of gas, water and electric meters, set programmable thermostats and receive important messages from their utility providers.
You could perhaps build your own platform, but only with significant investments in development, man hours and money in order to achieve the full range of features and functionality that are available from Device Cloud today. Keep in mind that during this development time Device Cloud will continue to advance. The primary benefit of Device Cloud is cost; we are continually investing significant R&D resources to deliver world-class scalability, reliability and security at the lowest cost possible.
Only a prebuilt, cloud-based solution can offer full-feature, production-class capabilities to an initial pilot and proof-of-concept. Device Cloud enables application developers to bring their solutions to market quicker than ever before.
Yes. Our security policy is based upon a control matrix developed to support the standards set forth by the National Institute of Standards and Technology (NIST), ISO/IEC 27002, North American Electric Reliability Corporation – Critical Infrastructure Protection (NERC-CIP) and the Cloud Security Alliance (CSA). The Security Policy is based upon 175 controls aligned with the following security standards: NERC/CIP, PCI, HIPAA, CSA, ISO27002 and NIST. We monitor our platform 24/7 and it is hosted in a SSAE16 (formerly SAS70) accredited facility.
Originally, devices were expected to keep a persistent network connection open to Device Cloud. An occasional heartbeat/keep-alive was sent in the absence of application data to confirm the link. Device Cloud now includes Short Messaging System (SMS) for deployment scenarios where bandwidth costs are premium. Some actions, like reboot, may actually be initiated over SMS. For more complicated transactions, Device Cloud can send an SMS request connect "shoulder tap" which will cause the device to initiate a traditional connection back to the server. Once connected, web services requests and UI actions can be made to the device.
Yes. Design help is available from many sources. The free Dia framework includes reusable software modules and open source code. The free integrated development environment (based on Eclipse) includes meaningful examples and tutorials. We also offer custom application development.
Professional design services are also available from Etherios Wireless Design Services. As an innovative wireless design company, WDS also carries deep expertise in embedded design services, software services and printed circuit board design.
There are currently two device clouds, one in the US and one in Europe. When creating a Device Cloud account, you can select a device cloud. We recommend you select the cloud closest to where the majority of the devices that you will register to Device Cloud are located.
Simply create a free account and enjoy access to Device Cloud services, including Device Manager (up to 5 devices), Web Services, SMS and Data Streams. Watch the Device Cloud Guided Tour video or request a one-to-one guided tour.
SCI (Server Command Interface) is one of the web services interfaces that allows users to perform commands and access information that relate to their device. Many of those commands utilize RCI (Remote Command Interface), a protocol that defines settings and capabilities specific to each device type and version. Examples of these requests include retrieving and setting configuration parameters, updating firmware, retrieving and updating files, working with XBee devices, and others.
More information on SCI is available at www.digi.com/wiki/developer/index.php/SCI.
Customers are able to build custom remote sampling solutions that report data through Dia. The data will be stored in the database on Device Cloud using DIA tables (instead of the original method of being stored as files). This will allow Device Cloud client applications to query Dia tables directly with web service calls rather than downloading and parsing XML files.
More information on the Dia API is available in the Documentation tab in the platform.
Remote devices that conform to the ZigBee Smart Energy profile will report data to Device Cloud. The data is stored in the database on Device Cloud using Smart Energy tables. This allows Device Cloud client applications to query tables directly with web service calls.
Please refer to the documents listed under "Smart Energy Resources" in the Documentation tab in the platform.
A client application may poll a remote device directly through Device Cloud. Alternatively, the remote devices may be configured to push data up to Device Cloud at a controlled rate (i.e., transmit once per minute) or under certain conditions (i.e., transmit immediately when value >50). Advanced querying of data is possible when devices push data up to short-term storage on Device Cloud. Client applications can then build more sophisticated queries such as "list all sensors that have a temperature over 100 degrees" or "list all devices that have not uploaded data in the last 24 hours".
For both designs, the client application will use web services to retrieve the data using Device Cloud. A client application may poll Device Cloud for new data or register to monitor various data elements and have Device Cloud push them to the client application when those elements change.
More information on the web service calls is available in the "Programming Guide" available in the Documentation tab in the platform.
A web service is a method of communication between two electronic devices over a network. Representational state transfer (REST) attempts to describe web service architectures that use HTTP or similar web protocols by constraining the message interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP).
The Web Services API exposes a number of functions via web services that allow devices and client applications to send data, retrieve data, change settings, update firmware, etc.
More information on the web service calls is available in the "Programming Guide" available in the Documentation tab in the platform.
Please see the API Explorer tool in the Help tab in the platform, where you can select example web service calls from easy-to-navigate drop down menus. The equivalent, detailed HTTP methods are displayed for review. Users may click to transmit any web service call to live, target devices, and the response from the remote device is displayed for review.
Any M2M device can be integrated with Device Cloud. While all Digi devices support Device Cloud out-of-the-box, any 3rd party M2M device can be integrated with Device Cloud by using Etherios Cloud Connector™.
The Gateway Development Kit is a great resource. It is designed to make it easy to setup a ZigBee network, upload a custom Dia application, and provide seamless connectivity to Device Cloud for web services integration to standard business applications over the Internet. The Gateway Development Kit includes an example application that is used to communicate with Device Cloud, display sensor values on a web page, and pass commands down to a device.
Digi ESP is an integrated IDE based on Eclipse that includes Python scripts, sample code and tools which have been designed to facilitate the development of applications for Digi devices. Digi ESP provides an ideal development environment for beginners and experts. Digi ESP is available for both Microsoft Windows and Apple Mac OSX platforms at www.digi.com/esp.
Dia (Device Integration Application) is software that simplifies connecting devices (sensors, PLCs, etc.) to communication gateways, allowing customers to build custom remote sampling solutions that report data through DIA. The data will be stored in the database on Device Cloud using DIA tables (instead of the original method of being stored as files). This will allow client applications to query DIA tables directly with web service calls rather than downloading and parsing XML files. You can enable this feature using the Dia data service subscription. It includes a comprehensive library of plug-ins that work out-of-the-box with common device types and can also be extended to include new devices.
More information on the Dia API is available in the Help tab in the platform.
Yes. Device Cloud-enabled devices initiate a client-side IP connection to Device Cloud. This mechanism is the most compatible with common firewall configurations, including the Network Address Translation (NAT) services delivered on most home internet routers.
Device Cloud includes support for the Short Messaging System (SMS) protocol. This technology allows cellular devices to drop their client-initiated connection when it is not required to reduce data usage. Device Cloud has the capability to send a short "shoulder tap" SMS message to the cellular device to request that it reinitiate the management connection if necessary.
By default, yes, however this is configurable. Device Cloud executes a variety of operating functions in the background to provide the customer with the status of devices in the network, including pushing a ping to the device to determine if it is still connected. The default for this ping is every 15 minutes, but can be adjusted by the customer if necessary. For example: battery powered devices. Even though the ping requires very little resources it can accelerate the consumption of the fixed power resource from the battery. In this event the customer may choose to decrease the frequency of the ping dramatically. This type of "are you still there" transaction is not counted towards the customer's chargeable transaction count from Device Cloud (although cellular carrier data usage may still apply.) It is considered platform administration.
Short Messaging System (SMS) functionality allows a cellular device to drop the persistent management connection indefinitely. Device Cloud can send an SMS "shoulder tap" notification at any time that requests the device to re-initiate the client-side connection to Device Cloud when it is needed.
Multiple options are available to connect machines/devices to Device Cloud that originally lack a network connection. Analog and Digital outputs from the machine or device may be collected by a gateway. That gateway, in turn, can make the connection to Device Cloud via wired, Wi-Fi, cellular or even satellite connections.
When multiple machines or devices co-exist in a physical location, it is possible to place an inexpensive XBee wireless module on each of the machine to collect the analog or digital data. Then a single gateway collects the sensor readings from each of the wireless XBee modules on all of the machines and reports the data up to Device Cloud using a single network connection.
Digi devices equipped with the Iridium Satellite module are able to use the Iridium Satellite network, where traditional Internet connectivity is not available.
Our security policy is based upon a control matrix developed to support the standards set forth by the National Institute of Standards and Technology (NIST), ISO/IEC 27002, North American Electric Reliability Corporation – Critical Infrastructure Protection (NERC-CIP) and the Cloud Security Alliance (CSA). The Security Policy is based upon 175 controls aligned with the following security standards: NERC/CIP, PCI, HIPAA, CSA, ISO27002 and NIST. We monitor our platform 24/7 and it is hosted in a SSAE16 (formerly SAS70) accredited facility.
Data held within Device Cloud is backed up to magnetic tape. Those tapes are taken offsite and stored with Iron Mountain.
Etherios is not currently registered for the Safe Harbor program. Registration is not necessary to remain compliant with EU legislation; however, Etherios is actively pursuing Safe Harbor registration and anticipate that registration will take place during 2013.
Etherios can comply with this request. All scans need to have prior whitelisting notice. With prior whitelisting, the IP scope can be scanned at any time.
Our NIDS system is provided by a top provider. This device is updated daily for new signatures and hot IP lists. Any alert from the NIDS system will be followed up within 10 minutes by a 24x7 NOC. The incident will be investigated by a certified security professional and any actions will be documented within the incident system. Actions may include blacklisting IPs or other actions deemed appropriate to mitigate the risk. Although HIDS is typically not required for many security frameworks, Etherios is in the process of implementing a behavioral based HIDS solution (NON Pattern based). Any alerts from the HIDS system will follow the same incident path as a NIDS incident.
Incident response will go through procedure to characterize and classify events. Response actions and incident handling procedures will be followed, as well as communication plans for those specific events. If an event is considered a customer-reportable or authority-reportable incident, those organizations will be notified. A monthly follow-up will be conducted with incident plans updated for future incident handling.
Etherios’ first response is to contain and evaluate the breach situation. Any breach would go through a case-by- case basis to determine if notification is required; all applicable laws and data classification policies will be consulted. Once notification has been determined, notification to reliant will be as soon as possible, provided that this will not harm the investigation or if law enforcement requests the delay in notification.
Currently our policy states that all Personally Identifiable Information (PII) must be encrypted by the end user and the encryption keys NOT passed through Device Cloud channels. It is our policy to encrypt PII data at rest; however, if PII data is already encrypted prior to being sent to Device Cloud, then Device Cloud will store the encrypted data. Device Cloud takes great strides in making sure that data is encrypted in transit, but because of the nature of the Internet, Device Cloud cannot guarantee the security from a device to Device Cloud on the Internet.
Etherios validates that all individuals working on the infrastructure will have a clean background check. Personally identifiable information (PII) results of individual background checks cannot be provided outside of Etherios and our cloud providers due to security concerns.
Yes, Device Cloud hires a leading pen test company to conduct a yearly pen test on our infrastructure.
All security, NIDS traffic and authentication logs are centrally logged on a non-alterable system. These logs are maintained for 1 year near line storage and 3 months online storage.
Device Cloud follows the CIS standards. Prior to implementation, vulnerability scanning and patching are performed on any new machine, with each issue addressed. Any ports not deemed critical to the application are either disabled or firewalled off. This can include special rules within our HIDS product, to lock down the “use” of the system to that specific application.
All Device Cloud Windows servers have AV installed. Each AV client reports to a central management server and definitions are updated every 4 hours on each client. If a client’s AV software fails or goes out of compliance, an alarm is generated and sent to our SIEM system. We also conduct a daily review using the AV management console to validate the current status of each client. If a client is found to be no longer updating, we correct this within 24 hours. All AV log information is saved for a minimum of 1 year in our SIEM.
Device Cloud tracks all security patches for each piece of software in our production environment. The CVSS score of each patch is evaluated for applicability and total risk. If the risk score is critical, an incident is opened, and the risk is mitigated either by a NIDS/HIDS rule, or a patch. If the risk can be mitigated by HIDS/NIDS, then we will install the critical patch within 30 days. For any other security patches, it can be a quarterly patch cycle.
Device Cloud has a system availability tool in place to monitor all Device Cloud critical hosts. There is a NOC that is staffed 24x7 that will respond to any outages. For the integrity of the hosts, the HIDS/FIMS and SIEM products monitor all critical files. The SIEM alerts will be responded to within 4 hours. For all FIMS alerts, these will be reviewed on a daily basis and coordinated with change control. For critical files, these alerts will be responded to within 4 hours.
All password requirements follow the CIS standards. These standards are:
- Passwords must be a minimum of 8 characters long and comprise 3 or 4 types of categories (upper case letters, lower case letters, numbers and special characters).
- Temporarily lock accounts after 5 bad password attempts within 60 minutes, and lock for 30 minutes.
- Passwords must be stored in an encrypted method (not plain text)
All storage of data follows our corporate data retention policy. Data scheduled for deletion follows automated processes. If the media is to be physically removed, it follows the standard DOD.5520-22 M 7 pass deletion. For destroyed media, an authorized vendor issues a certificate of destruction.
Etherios defines data level encryption by first classifying the level of data that will be stored and transmitted with the application. Device Cloud has defined 4 levels of data. Level 1 is considered public information and is not encrypted. For level 4 data, commonly known as Personally Identifiable Information (PII), or Non-Public Personal Information (NPI), Device Cloud devices can encrypt data in motion using standard FIPS-140 compliant encryption (AES128/256 bit). For level 4 data, Device Cloud’s policy is also to encrypt this data with disk level encryption while this data is “at rest.” At this time Device Cloud does NOT accept level 4 data from any customer unless the customer has already encrypted the data prior to giving that data to Device Cloud. Device Cloud also does not accept the encryption keys for storage on the platform. The encryption keys must be kept by the customer “out of band” to the Device Cloud application.