Smart Systems Platform


Smart Systems acquire relevant data, evaluate the real time situation represented by that data and respond to the identified situation either by taking a direct, automated action or by advising a user or another system that an action is warranted by the current situation. Such a system consists of data definitions for storing the sensor data and the situational state, logic for detecting and responding to situations, and data transport to move the data to the appropriate location for evaluation and storage.

For example, a specific situation might be defined as:

If all these conditions are true, the desired situation is encountered and the system might notify an application that will then recommend various courses of action for the user. For example, the system might offer to bring the user hot coffee or perhaps offer to sell them a souvenir waterproof jacket. In real time or near real time environments, processing is always better performed locally to the device under control improving response time and reliability. For example, in an industrial setting, managing the position of a materials handling system requires near real time responses within a few hundred milliseconds. Such response times cannot be guaranteed by a remote decision making system that may be delayed by 1,000’s of milliseconds if there is network congestion. Vantiq is a high productivity, high-performance distributed system. Vantiq consists of:

The solution affords the user high productivity by supporting the specification of the automation system at a much higher level than traditional service platforms. It also offers a set of tools that make the development, deployment, operation, and management of the automation system as easy as possible. Since the data is externally sourced and the results must be delivered to external systems, a key to high productivity is flexible but simple integration capabilities for sources and devices. Vantiq offers high performance by supporting a highly scalable cloud architecture incorporating a number of performance specific optimizations, as well as local service deployments to support processing distributed to the network and to private data centers. The solution is fully distributed supporting the TRANSPARENT development and optimization of automation solutions that span all layers of the distributed environment.

Conceptual Model

New events stream into the service from external data sources. If the arriving data is relevant to a particular rule, the rule is “triggered” and scheduled for execution. The rule may update the model state and, if the defined situation is detected, the corresponding actions defined by the rule are executed.

Vantiq detects specific situations as defined by rules. The rules are activated by changes to data streams that are presented to the service. In the above example, the data streams might be the weather conditions, the user’s location, and the baseball game’s state.

The actions taken when a situation is detected might deliver notifications, request a recommendation, or change the situational state.

Defining Data Streams

The first step in creating a solution is to define the inbound data. Multiple data streams may be defined. In the above example, three streams were defined:

Each stream is represented by a type in the automation data model. The types are defined by the application developer and their definitions are only constrained by the capabilities of the data model.

Processing is initiated when an object is inserted, updated, or deleted in one of the data stream types. For example, the Weather type could be defined using the JSON representation:

    "name": "Weather",
    "properties": {
        "location": { "type": "GeoJSON" },
        "temperature": { "type": "Integer" },
        "windSpeed": { "type": "Integer" },
        "visibility": { "type": "Integer" },
        "precipitation": { "type": "Real" },
        "overallEvaluation": { "type": "String" }

Types, along with all other system objects, may defined using the Developer Portal, the Vantiq CLI or the Vantiq REST service. The specific Vantiq REST commands for creating types can be found in the Resource Reference Guide.

Once the automation data streams have been defined, it is the responsibility of the developer to provide the data feed to deliver objects of the stream type. Vantiq offers a number of pre-packaged external sources that are easily configured to read a data stream from an external system. For example, a source could be defined to read the Weather from a weather service:

    "name": "WeatherSource",
    "type": "REMOTE",
    "direction": "SOURCE",
    "pipelineRules": ["ingestWeather"],
    "config": {
        "serverURIs": [""],
        "username": "vantiq",
        "password": "vantiq",
        "queryForm": "url",
        "pollingInterval": 60

This source will issue a GET on the URI every 60 seconds. When a response is returned, the ingestWeather rule is invoked to process the inbound weather data.

Alternatively, an application might be created to obtain the relevant weather information for the user’s location. The data is then added to the stream using INSERT, UPDATE and DELETE commands from the Vantiq REST API. For example, to stream a new weather report the following INSERT could be issued:

    "location": {"type": "Point", coordinates: [122.3892, 37.7786]},
    "temperature": 57,
    "windSpeed": 12,
    "visibility": 1,
    "precipitation": 0.1,
    "overallEvaluation": "poor"

The specific REST commands for INSERT, UPDATE and DELETE on the data model can be found in the API Reference Guide.

This query might be issued every 15 minutes to update the current weather conditions.

The INSERT of the new weather condition will trigger any automation rules that have declared weather as a triggering condition.

Defining Situations

Once the automation data streams are defined, the representation of the situation itself is defined. The situation is represented by a state. Either a new type is defined that represents the situation or additional properties are added to an existing type to represent the situation. For example, a new type could be defined that identified the user and their current state at the ballpark:

    "name": "BallparkSituation",
    "properties": {
        "username": {"type": "String"},
        "currentLocation": {"type": "GeoJSON"},
        "currentSituation": {"type": "String"},
        "proactiveActions": {"type": "String", "multi": true}

The current situation might be one of:

The states would be computed by the automation rules and stored in BallparkSituation.

Defining Automation Rules

With the automation data streams and the situations defined, the final step is to define the automation rules. Each rule is triggered by a change in the data streams. Once triggered, the rule is scheduled for execution. Execution involves calculating a context and then evaluating each rule against the context. If a rule’s condition is satisfied, the rule action is executed. Rule actions may cause the situation to change, which may, in turn, trigger other rules. Processing continues until all rules triggered, directly or indirectly, by the initial state change are evaluated.

Automation rules are defined using the notation defined in Rule and Procedure Reference Guide and registered with the automation services using the REST API. The example ballpark application might have rules such as the following defined:

RULE uncomfortableConditions

WHEN INSERT OCCURS ON Weather:w WHERE w.location == "ballpark"

SELECT BallparkSituation

for (b in BallparkSituation) {
    if (w.temperature < 55 && w.precipitation > 0.05) {
        UPDATE BallparkSituation(currentSituation : "uncomfortably cold",
                                temperature: w.temperature)
                                WHERE _id == b._id

This will be triggered by a new weather event and will evaluate BallparkSituations with respect to the new weather condition if the weather condition applies to the location of the ballpark. If the weather is poor, the current situation is updated. The update triggers a second situational rule to produce a recommended action.

RULE uncomfortableGuest

WHEN UPDATE OCCURS ON BallparkSituation:b

if (b.currentSituation == "uncomfortably cold") {
  PUBLISH REQUEST ON BallparkSituation WITH b
  PUBLISH { body:b } TO SOURCE guestServices

if (b.currentSituation == "uncomfortablly warm") {
  PUBLISH REQUEST ON BallparkSituation WITH b
  PUBLISH { body:b } TO SOURCE guestServices

This second rule produces possible actions to take on behalf of the guest and sends them to the guest services app presumably to produce offers for the guest delivered to their mobile device. Note that the actual implementation of the recommendations is the responsibility of the application using the automation service. The automation service simply identifies the situation of interest and, optionally, produces recommendations to be delivered to the business app.

The recommendation rule might look something like:

RULE coldGuest

WHEN request OCCURS ON BallparkSituation:b
  WHERE b.currentSituation == "uncomfortably cold"

SELECT BallparkOffers WHERE offerType == "uncomfortably cold"

FILTER offer in BallparkOffers RECOMMENDATIONS TO GuestRecommendations
UNTIL GuestRecommendations.size() < 5 DO
        if (offer.idealOfferTemperature > b.temperature - 5 &&
            offer.idealOfferTemperature < b.temperature + 5) {

This will produce a list of recommendation for offers that are “optimal” for temperatures within +- 5 degrees of the current temperature.

Another Weather Rule

This example sends a notification to an external system at the endpoint specified and updates the WeatherSituation type with the newly identified situation:

RULE weatherExample


if (Weather.temperature < "50F" && Weather.windSpeed > "10MPH" &&
    Weather.precipitation > "0.1 inches") {
    PUBLISH {"body": {"situation": "poor"}} TO SOURCE weatherAdvisory
    UPDATE WeatherSituation(date: ars_currentDateTime, situation: "poor")
        WHERE location == Weather.location

The situation is named “weatherExample” as specified in the “RULE” clause. The triggering condition is a change to the “Weather” type as specified in the “WHEN” clause. A change to Weather causes a re-evaluation of the current WeatherSituation. The rule states that if the current temperature is less than 50 degrees F and the wind-speed is greater than 10 MPH and the precipitation is greater than 0.1 inches the current weather situation should be updated to “poor”. The THEN clause publishes a notification to the specified URL and stores the new situation in the WeatherSituation type.

Using the Documentation

These simple examples illustrate essence of automation using Vantiq. The remainder of the documentation provides a number of fully worked examples as well as descriptions of each Vantiq feature and the details necessary to use the feature effectively.

We recommend starting with the tutorials that contain fully worked example automation systems:

The API Reference Guide and the Resource Reference Guide contain detailed information on the available resources and the structure of the REST API for accessing the resources. The Rule and Procedure Reference Guide describes all the features available for creating rules to ingest data, identify situations and produce actions and notifications.

The resources can also be accessed from the Developer Portal and from the Vantiq CLI CLI Reference Guide.

The integration of external sources and systems is documented in the Source Overview and the Adapter and Connector Overview.