Splunk data models are hierarchically structured search-time mappings of semantic knowledge about one or more datasets within Splunk. They serve to organize and simplify complex data, making it more accessible for analysis and reporting, especially for users who may not be proficient in Splunk Search Processing Language (SPL).

Splunk Operational Technology Intelligence (OTI) ships with the OT Sample Data Model to help users achieve this goal for organizing OT data no matter the assets it is coming from. Events that conform the OT Sample data model are related to observations that are continuously changing (such as sensor data). On top of the inherited fields from Splunk events *, the following fields are available in the OT Sample data model:

** Units is not a required field in the data model, but it has a column in the Namespace dashboard, so it's a recommended field. See the Namespace dashboard section for more information.

For an event to conform to the OT Sample data model, it must match the following constraints:

• An event must have all the required fields by the data model. These fields can be supplied either in the source (where the data is generated, if possible) or using Splunk features such as field aliases, calculated fields, lookups, etc.

• An event is required to be tagged with the ot_observation and ot_sample tags. For more information see the section on how to add tags using event types.

• As a best practice, there is a limitation in terms of the indexes where the dataset can be generated from. As part of OTI, the ot_sample_indexes search macro is available and all target indexes for the OT Sample data model are required to be included in the search there. Please refer to the next section for details on how to update it.

For performance reasons, data model acceleration is the best practice. Acceleration takes additional resources, and the data models cannot be accelerated by default on the OTI app installation. If you decide to do so, the OT sample data model can be accelerated by navigating to Settings, and then Data Models, and then OT Sample, and then Edit Acceleration. For more details on data model acceleration, see the Accelerate data models topic in the Knowledge Management Manual.

Add index data to the OT sample data model

To use your OT data in the OTI app, it must conform to the OT Sample Data Model. This can be accomplished either by formatting your data before indexing or by manipulating already indexed data. This guide covers the process of adapting existing indexed data.

1. Configure the OT Sample Data Model

   1. Update the Data Model's Index List

      1. Navigate to Settings, and then Data Models, and select OT Sample.

      2. For an event to be included in the data model, it must meet the following constraints

         1. The event's index must be in the ot_sample_indexes macro.

         2. The event must have the tags: ot_observation and ot_sample.

   2. Update the list of indexes

      1. Navigate to Settings and then Advanced Search and then Search Macros.

      2. Edit the ot_sample_indexes macro to include your index.

2. Tag Events Using Event Types. Events must have the ot_observation and ot_sample tags. Typically, this is managed with event types. To create an event type, perform the following steps:

   1. Navigate to Settings, and then Event types, and then New Event Type.

   2. Define a search string to capture your desired events. For example, sourcetype=your_sourcetype.

   3. Assign the tags: ot_observation and ot_sample.

   4. Optionally, select a color to highlight these events in searches.

   5. Verify your configurations by searching for events using your event type in Apps, and then Search. Matching events should appear with the selected color and the correct tags. For more information on event types, see the About event types topic in the Knowledge Management Manual.

3. Ensure required fields exist.

   1. Review your configurations to verify that the following fields exist.

      1. Name and value

         1. If these fields are not present, you can create them at search time using field transforms.

         2. For examples of field aliases, calculated, and extracted fields, review definitions under Settings, and then Fields in the OTI app.

      2. Location (unified namespace)

         1. This field should contain the path of a location, device, or sensor in a unified namespace.

         2. It can be created using field transforms or Splunk lookups.

   2. Example: Create a lookup for location mapping.

      1. Prepare a CSV file mapping source event values to locations:

         1. For example, see the following table:

         2. Serial	Location
            Q3CA-NZDT-MELE	/Splunk/Boston/ProductionLine1/Processing/WorkStationSensor
            Q3CA-WERT-LERO	/Splunk/Boston/ProductionLine2/Processing/WorkStationSensor

      2. Navigate to Lookups, and then Lookup table files, and then Add new to upload the CSV.

      3. Navigate to Lookups, and then Lookup definitions, and then Add new and reference your CSV.

      4. Navigate to Lookups, and then Automatic lookups, and then Add new to map fields from your events to those in your CSV. Make sure to select "Override field values" if your original events already include a default location field. For more information on lookups, see the About lookups topic in the Knowledge Management Manual.

4. Validate Events in the OT Sample Data Model

   1. Run a search on your index. Events recognized by the data model should have:

      1. The ot_sample and ot_observation tags

      2. The fields name, value, and location

      3. Test with the following search: | from datamodel:"OT_Sample.ot_sample" | search

         1. Correctly configured events will be included in the results.

   2. Alternatively, review data in: Search, and then Datasets, and then OT Sample, and then ot_sample.

5. Handling events with multiple values.

   The OT Sample data model requires a single name/value pair per event. If your source events contain multiple samples, split them into separate events.

   Options:

   Before indexing	Use tools like Splunk Edge Processor.
   After indexing	Use scheduled searches (cron jobs) to transform and re-publish events.

   For more information, see the Schedule reports topic in the Reporting Manual.

Troubleshooting Checklist

• Confirm events have the required tags and fields: name, value, and location, and the tags: ot_observation and ot_sample.

• Only events in indexes defined in ot_sample_indexes are recognized.

• If events aren't recognized, recheck event types, field extractions, and lookup definitions. Pay attention to app permissions for all these definitions.

• Ensure field extractions and lookups are applied to the correct source type, source, or host.

• Use dataset views to verify inclusion.

• Events must be split if they contain multiple sample values.

Edge Hub Data and the OT Sample Data Model

OTI makes it easier to configure edge hub data to conform to the OT Sample data model. This is done through the edge_hub_ot source type that not only conforms edge hub data to the data model, but also provides you an example to create your own source type to conform OT data coming from other sources.

Use the Data Ingestion section in the OTI app to create a new datastreamer that will subscribe to the sensor data topics (edgehub/+/+/values) using an event index. Select the edge_hub_ot as the source type for this datastreamer.

While the source type will handle the field and tag conformity to the OT Sample data model, It is important the the event index selected in the datastreamer configuration is also part of the ot_sample_indexes search macro, as this is the one remaining constraint required by the data model to generate the dataset. Once data is ingested from the configured datastreamer, it can be searched by using the following base SPL query, that can be enriched by filtering desired data:

| from datamodel:"OT_Sample.ot_sample"

In addition to this, the incoming data from edge hubs through this datastreamer configuration can also be seem in the Unified Namespace dashboard available in the OTI app.

Custom configuration to conform events to the OT Sample Model

You can use the edge_hub_ot source type as an example to create your own configuration to conform data from other OT data sources. Please follow the steps below to do so.

1. Create a new custom source type or clone one of the pre-existing source types available in the Splunk software.

   1. While edge_hub_ot was created as a custom one, you can clone existing source types such as _json or csv, depending on the format of data you dealing with. Source types can be created by navigating to Settings, and then Source types.

2. With your new source type, create an event type that will tag your events.

   1. By navigating to Settings, and then Event Types, you can locate the edge_hub_internal_sensor event type that searches for all data matching the edge_hub_ot source type and applies the ot_observation and ot_sample tags to the data (as well as changing the color and priority in results.

3. Based on your data, supply the fields provided through the OT Sample data model. While for conformity only the required ones are strictly needed, it may be useful to map the non-required ones to provide you a common foundation. This can be done through the field aliases, calculations, extrations, transofrmations or lookups.

   1. Field aliases: Use field aliases when a simple mapping from existing fields to new fields is required. This can be found by navigating to Settings, and then Fields, and then Field Aliases. For more information, see the Create field aliases in Splunk Web topic in the Knowledge Management Manual.

      1. the edge_hub_ot source type has field aliases supplying the nt_host and value fields. nt_host is being created simply as an alias for host, while value has a more elaborate rule that is making it an alias for all the metric values from Edge Hub data.

   2. Calculated fields: Use calculated fields when expressions are required to set to generate the values for new fields. This can be found by navigating to Settings, and then Fields, and then Calculated Fields. For more information, see the About calculated fields topic in the Knowledge Management Manual.

      1. The edge_hub_ot source type has calculated field eval expression for the name, location, native_protocol, statistic and statistic_period_seconds fields.In some cases it's a simple string assignment, in others case clauses are used to determine what will be assigned to the field.

      2. There are also calculated fields based on the source field from Edge Hub events. The source field carries the topic where data is originated in the Edge Hub, and contains more specific information about the metrics generated. value, type, units, description and native_units (when applicable) are populated this way.

4. After this setup is complete, verify that the source type created to the events from your OT data source in your input configuration has been set. For example, the event payload sent in a request to the HTTP Event Collector or the Splunk Universal Forwarder configuration.

Meraki Data and the OT Sample Data Model (using Edge Hub MQTT Broker)

OTI makes it easier to configure Meraki sensor data to conform to the OT Sample data model. This is done through the meraki::sensorreadingshistory source type and currently provides an example on how that can be achieved using a temperature/humidity Meraki MT-10 sensor as a sample device. The following directions are required to ingest Meraki data using an Edge Hub device:

1. Enable the External MQTT Broker in the target Edge Hub device. Take a note on the IP address of the Edge Hub. While the port to be used will be 1883, you can configure additional security settings such as authentication and certificates, if needed.

2. In the Meraki dashboard, find the topics corresponding to the sensor data required for the Splunk software.

   • Humidity, temperature and battery metrics are currently configured for the source type.

3. In the Meraki dashboard, configure the target broker with the settings from the edge hub external MQTT broker.

4. In your Splunk platform deployment, create an event index that will ingest the data from your Meraki device.

5. Update the ot_sample_indexes search macro with the selected index.

6. In the OTI app, configure a datastreamer that will listen to one of the following topic pattern: edgehub/mqtt_events/# (wildcard that subscribes to all messages delivered through the edge hub external MQTT broker) or edgehub/mqtt_events/<Meraki topic from earlier in these steps> (to subscribe specifically to the topics being used), using the selected event index and the meraki::sensorreadingshistory source type.

7. Wait a few minutes for the configuration updates to reach your Edge Hub.

Once data is ingested from the configured datastreamer, it can be searched by using the following base SPL query, that can be enriched by filtering desired data:

| from datamodel:"OT_Sample.ot_sample"

In addition to this, the incoming data from Meraki sensors through this datastreamer configuration can also be seem in the Unified Namespace dashboard available in the OTI app.

Meraki Data and the OT Sample Data Model (using Cisco Meraki Technical Add-On)

Alternatively, it is also possible to use the Cisco Meraki Add-on for Splunk to collect data from your Meraki devices instead of the Edge Hub's MQTT broker. With this approach, you must configure your Splunk instance with your Meraki credentials, store the data in a Splunk index, and use the preexisting (or define new) field transforms to conform the index data to the OT Data Model.

For example, perform the following steps to capture battery, humidity and temperature sensor data that is natively supported by the OTI app:

1. Download the Cisco Meraki Add-on for Splunk from Splunkbase, and install it on your desired Splunk instance.

2. Configure your Meraki credentials. See the Cisco Meraki Add-on for Splunk documentation for more information.

3. Navigate into the Input tab on the Cisco Meraki Add-on and create a new input for sensor reading history. Configure the Name, Organization, Interval and Start from fields.

4. Select the index in which your Meraki sensor data events will be stored. Note that this index must be added to the ot_sample_indexes search macro used by the OT Sample data model.

   1. You can confirm or update the indexes defined in the macro by checking its definition by navigating to Settings, and then Advanced Search, and then Search macros.

   2. Note that the macro is preconfigured with an index named "main_meraki", but it can be freely updated.

5. Confirm that the sensor data is flowing to the index with a search on the index. The sensor data should have a sourcetype set to meraki::sensorreadingshistory.

6. Perform the following Splunk search to confirm that the sensor data is correctly conformed to the OT Sample data model:

   | from datamodel:"OT_Sample.ot_sample" | search sourcetype="meraki:sensorreadingshistory"

7. The OTI application includes field aliases and transforms for these Meraki sensors. See their definition under Settings, and then Fields, and then Field Aliases. To add support for other types of data from Meraki devices, add them as an input to the Cisco Meraki Add-On and create field aliases or transforms that use the sourcetype of these new events.

   For more information see the Adding Index Data to the OT Sample Data Model in this manual.

Unified Namespace Dashboard

A common foundation can be achieved when conforming your OT data to the OT Sample data model. Searches, reports, alerts and dashboards can be created using the same data structure, no matter the origin. The most immediate benefit from this comes in the form of the Unified Namespace dashboard of the OTI app, which can be found by navigating to the OTI app, and then Dashboards, and then Unified Namespace.

The Unified Namespace dashboard offers a common view where the events (called observations in the context of the data model) for all devices can be listed under a tree structure. The following fields from the OT Sample data model help to put this vision together:

Filters

The dashboard makes use of filters to help visualize the data in your tree structure.

• Time Range offers the traditional time selection dashboard from Splunk where the user can choose between available presets and range formats. Defaults to last 30 minutes.

• Location Filter allows you to pick a particular location from your hierarchy (each section of the location field from all observation becomes a searchable item under this filter). Defaults to All.

• Metric Filter allows you to pick a particular metric across all metrics reported by devices conforming to the data model. Defaults to All.

• Temperature Units allows you to select the desired unit for temperature, performing required conversion depending on the value selected. Defaults to Celsius.

• Pressure Units lets you to select the desired unit for pressure, performing required conversion depending on the value selected. Defaults to Pascal.