Listen to this page: audio icon

Getting Started

Example Platform Overview

On this page...

Introduction
Founding vision

The Example Platform Specification vision is to align leading suppliers of sensors, Device module makers, and cloud system solution providers to Example to drive adoption. It focuses on Cloud-based storage, apps, and services to invite global competition and to improve security. Example technologies propel and advance computers to bring forth the next generation of smart Devices through a strategic alliance and proprietary specification. This platform enables the sharing and processing of data.

Legacy Devices are designed to create images or videos that are consumed by humans.

Today the capabilities of Devices are becoming more sophisticated and the output of Devices is increasingly being processed by machines. Devices are still being designed as largely standalone isolated devices. There is no infrastructure for connected smart Devices.

These Devices produce a sea of video streams with no intelligence in their organization. This creates a mass of data in the cloud which is difficult to browse or search for any significant event. Example creates a structured way of processing data and making it easy to navigate. This includes having simple DeviceMarks comprising thumbnail images & metadata based indexes that enable the easy search of events.

When the data generated from the sea of video streams data is properly organized and analyzed with appropriate Artificial Intelligence and Computer Vision algorithms, it offers another dimension of utility services for consumers.

At the same time, consumer demand for high-end security Devices for personal use is increasing. More and more IP, IoT or personal/home assistance Devices need to incorporate features offered in high-end surveillance Devices. There is no consistent way for these Devices to be connected to the cloud and interact with readily available online AI based video analytic services.

  • Consumer IP surveillance Devices are installed close to each other.
  • They do not work in networked fashion, either among the Devices themselves or with other sensors or IoT devices.

Example defines a standard way for these devices to communicate with each other and collaborate to serve in better ways.

The connection of Devices to the Internet and the processing of the data created by these Devices in the cloud represents a serious security threat and challenge. There is a need to ensure that the data produced by these Devices is securely handled in way that enables privacy and control over what data is produced and who has access to data that is produced.

Example solves these issues by enabling Device makers to expose advanced capabilities in their Devices to application developers without requiring these developers to become expert on controlling specific Devices. It also enables the grouping of Devices from different Device makers to interoperate and work in conjunction with each other through a cloud platform. The following are a few key areas of what Example covers in this specification.

Due to the increasing mass demand of mobile applications, the modern sensor module has integrated more features such as lenses, exposure control including certain flashes, mechanical controls and multi-sensor image capture. The interface between these new types of sensor modules and application processors has become more complex, hence Example defines a packetized and scalable interface.

  • Known as a "lens mount", this similar interface also exists in traditional Devices.
  • Similarly, Example addresses "Integrated Device Mount" by defining how image capturing control and captured images are transferred between a sensor or Device module and application processors.

Ideally, this interface should be interchangeable, therefore having the capability to dynamically re-configure the interface when both wired (or wireless) interconnects are employed.

Since different sensor types or configurations are used in a Device, it is important that the Device service stack or API must be able to identify and handle any types of configurations, especially when such mount is dynamic. Example defines such interchangeable Device module API and configure corresponding service layer stack accordingly to get ready to control Device module with various capturing options.

As different applications that use the Device may want to capture a frame or multi-frames of images differently for various purposes and also for analytic efficiency, the Device service stack must be able to handle such a demand. Example defines such an API as a "Device-based" API between an end applications' semantic to Device capture control.

There are certain applications using Device-captured images or video that utilize additional metadata associated with the captured image, to more accurately analyze the situation the Device is capturing. Such metadata may include audio, adjacent Device's image or other sensors’ data, location, processed image data, etc. Depending on the semantics of the application, this metadata may vary and it influences how Device captures the image and what and how to process the image for.

Example introduces Device, DeviceMode and DeviceData to address how applications and the Device work together. Analytic picture/video applications require all possible data gathered at a certain "Device' (e.g., Crime Device data). There may be different Devices for every differing purpose of analytics, and hence Example defines DeviceMode as a "Mode" rotating control in traditional Devices to better capture images using ideally set parameters.

DeviceMode then defines fixed DeviceData that the Device module returns. The data may include frames captures in certain capturing parameters, as well as having certain parts of an image being processed by local application processors.

▲ Top

Cloud API
A key element of Cloud API is that it is agnostic and independent of any operating system or sensor type.

DeviceMode enables communication between Example devices, allowing for more relevant image capture and delivery of pertinent data (DeviceData), as it relates to the local and surrounding sensors.

While it is dependent on the level of permissions granted by the given user, other third-party apps and service developers will also have access to the DeviceMark server, video cloud storage, live broadcasting, IoT controls and additional data feeds. Utilizing both the standardized Cloud API and revenue sharing App Store in tandem, will drive and promote new app ideas and services on Example compliant Example devices for third party developers.

▲ Top

DeviceMarking, DeviceData Stream, & Database
Traditional Devices output and record JPEG, MPEG or H.264 streams of video data, and this data is often browsed or searched by timestamps.

More recently, this data can now be accessed using special video analytics that recognize certain objects or events, which is then used to search the desired mark in the recorded database.

Example redefines the parameters for data storage and streaming - what needs to be stored and how the given data should be stored, indexed, and searched, for greater efficiency of user applications. As a solution, Example proposes DeviceMarks-based data organization, a platform that extracts vital information out of segments of data stream into compact DeviceMark datagrams with references to related DeviceData and other stored media, and stores and presents them through various end-user channels.

This can then be managed by a cloud-syncing server or indexed as thumbnail images for example, along with metadata, into a log-style archival container, ready for search by sophisticated filter criteria, i.e. combination of object image, audio or text attributes. DeviceMarks can be generated by the captured image itself, processed image data and primarily through automated analysis on image(s) and processed image data together.

▲ Top

Example Security System
The Example system addresses five security issues:
  • Network Security
  • Data Privacy
  • User Account Management
  • Cloud Security
  • Device Security
Network Security
The Network Security Function isolates the Example devices from the network hazard, reducing the ability of an outside attacker from exploiting weaknesses in the implementation of the Device. These weaknesses can be used to download rogue applications onto the Device (either to use the Device in an unauthorized manner, or to use the Device as part of a botnet). The Example system is equipped with a security module in the Device that enforces whitelists of clients to the Device and enforces traffic encryption.
Data Privacy
Example's Data Privacy measures ensure privacy of the data that is captured and generated. The Example system provides a fine-grained encryption of the data captured or generated, creating a privacy management system that enables access to control specific fields or segments of a video.
User Account Management
The User Account Management feature guarantees that any third-party applications are only given limited access to the data created and configuration of DeviceModes on the users’ network of Devices.
Cloud Security
To ensure the security of Example data of any sensitive nature, there are several aspects relating to security that need to be handled by the Example specification. The major security assets in the system are the user's account, the Devices, data (DeviceMarks and DeviceData) and Applications.

The following functionality is used to protect these assets:

  1. Device:
    1. Device Credential Management
    2. Device Management:
      1. Network Security
      2. Secure Time
      3. Code Signing
  2. User Account:
    1. Access Control
  3. Data:
    1. Privacy Management System
  4. Application:
    1. Application Key
    2. Credential Management
    3. Privacy Management System
Device Security

The Example system enables the Device to have a Firewall within the Device itself. The implementation of the Firewall may be:

  1. Within a trusted execution environment.
    • This provides the highest level of security.
    • This provides a defense even when the application processor on the Device has been compromised and simplifies the management of updates by enabling a single code image for security to be used on multiple Device models.
    • The details of the Trusted Execution Environment are out of scope of this specification. (Options that may be implemented are Global Platform or within the Android specification (Trustee)).
  2. Within the application processor.

Note: The implementation of the Firewall is determined by the Device manufacturer.

The Example system provides a standard mechanism to configure the following within the firewall:

  • Whitelist, Blacklist mode
  • Domain Name Filters
  • Port Filters
  • Protocol Filters
  • Specific patterns

▲ Top