8.10. Database Schema

This section details the Elasticsearch database schema for the VEDAR family of tools. The objective with this schema is to establish common data structures that can be used to build visualizations and dashboards in Kibana.

Elastic Common Schema (ECS) version: 8.10.0

8.10.1. Notes

• Elasticsearch is a NoSQL database, why is there a schema? Because we want to share data between users and tools, we want that data to have a predictable format. We want all of the VEDAR tools to “speak the same language” when it comes to data in the database.

• What data should conform to this guide? Any data that is expected to be seen by a user, or to be used by more than a single tool. Data that’s used internally by a single tool does not need to

  conform to this structure.

• Elasticsearch is a NoSQL database, so it does not have a “schema” like a traditional database does. In fact, you can ingest pretty much any arbitrary .json content into an Elasticsearch index.

• The schemas here are descriptions of the JSON fields expected of a “entry” in the Elasticsearch database (also known as a doc).

• “Data Type” values are Elasticsearch data types (reference). When storing as a plain JSON file, ensure the format it is stored in either matches or can be cohered to the corresponding Elasticsearch format.

• Fields listed as required must be included in any docs that contain the parent field. If the field is at the root level, it is required for any docs in that index.

• Fields listed as optional do not have to be included in a doc push. However, any data that matches that field must use that field and not a custom field.

• Additional fields beyond those defined here are permitted, provided they’re internally consistent (e.g. always the same for a version of a tool).

• These schemas follow the Elastic Common Schema (ECS). Changes must adhere to the ECS, when possible.

8.10.2. Indices

This section lists the Elasticsearch indices (aka “indexes”) used by PEAT, and what they are used for. Refer to the exemplar.json files for examples of data from these indices, and refer to the mapping.json files for the full index mappings for these indices.

• vedar-logs-[year].[month].[day]: Logs for PEAT. 1 document = 1 event.

• ot-device-hosts-timeseries-[year].[month].[day]: Results of PEAT pulls. 1 document = results from 1 device.

• peat-scan-summaries-[year].[month].[day]: Results of PEAT scans. 1 document = results from all devices in the scan.

• peat-pull-summaries-[year].[month].[day]: Results of PEAT pulls. 1 document = results from all devices in the scan.

• peat-parse-summaries-[year].[month].[day]: Results of PEAT parses. 1 document = results from all devices parsed.

• peat-configs-[year].[month].[day]: Configuration values used by PEAT for a run. 1 document = config values for a single PEAT run.

• peat-state-[year].[month].[day]: Internal state of PEAT for a run. 1 document = state values for a single PEAT run.

8.10.3. Universal Requirements

• ALL entries MUST include the Base and Agent field sets.

• ALL timestamps MUST be in the UTC timezone, in ISO 8601 format, and use the Elastic date data type.

8.10.4. Schema Update Process

There are a few ways the Schema we use will be updated:

• ECS Schema Updates: Elasticsearch regularly updates the Elastic Common Schema. We will bring in relevant changes from their updates into our schema.

• PEAT Updates: Updates to PEAT comes with new data in the database. Updates to this schema are included in this process.

8.10.4.1. Base Fields

Base Fields

Field	Data Type	Example(s)	Description
@timestamp	date	2016-05-23T08:05:34.853Z	When the tool collected the data.
ecs.version	keyword	1.9.0	ECS version this event conforms to. ecs.version is a required field and must exist in all events.
message	text	Some summary	Human-friendly summary of the Elasticsearch document (80 char max length). The intent is that these will show up on dashboards.
tags	keyword	[‘field device’, ‘config’, ‘change’]	Metadata that could potentially be used to filter or enrich events in a dashboard.

8.10.4.2. Agent Fields

Information about the tool that generated the event (PEAT). ECS reference: Agent Fields

Agent Fields

Field	Data Type	Example(s)	Description
agent.id	keyword	163737449406	Unique identifier for a running instance of the tool. In PEAT, this is the run_id.
agent.type	keyword	PEAT, Archimedes, Packets	Name of the tool.
agent.version	keyword	2.0.1.20210930	Version of the tool.

8.10.5. VEDAR Logs (vedar-logs-*)

Logs from PEAT, such as errors or informational messages. Note that this does not include logs collected from OT devices by PEAT, those fall under ot-device-hosts-*.

Note

The name is a legacy holdover, and will be changed in the future.

8.10.5.1. Notes

• Index: vedar-logs-<date>, where date is, year.month.day in UTC. Example: vedar-logs-2026.01.29

• message: Human-readable log message. No longer than 80 characters.

• Every entry includes the Base Fields and Agent Fields.

• The level and complete log entry text is contained in the log.* field set, defined below.

• Python logging.LogRecord objects can be used to populate all of these fields (logrecord attributes documentation).

8.10.5.2. Fields

ECS reference: Log Fields

Log Fields

Field	Data Type	Example(s)	Description
log.level	keyword	ERROR	The log level of the message. Typical values to expect are: CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE
log.logger	keyword	peat.protocols.snmp	The name of the logger inside an application. This is usually the name of the class which initialized the logger, or can be a custom name.
log.origin.file.line	integer	108	The line number of the file containing the source code which originated the log event.
log.origin.file.name	keyword	parse_api.py	The name of the file containing the source code which originated the log event. Note that this is not the name of the log file.
log.origin.function	keyword	save_to_file	The name of the function or method which originated the log event.
process.args	keyword	[‘peat’, ‘parse’, ‘--help’]	Array of process arguments, starting with the absolute path to the executable. May be filtered to protect sensitive information.
process.args_count	long	3	Length of the process.args array.
process.command_line	keyword	peat parse --help	Full command line that started the process, including the absolute path to the executable, and all arguments. Some arguments may be filtered to protect sensitive information.
process.executable	keyword	/venv/bin/python	Absolute path to the process executable.
process.pid	long	357	Process ID (PID) of the process the log event originated from.
process.parent.process.pid	long	444	Process ID (PID) of the parent process.
process.name	keyword	MainProcess	Name of the process the log event originated from.
process.start	date	2016-05-23T08:05:34.853Z	The time the process started.
process.working_directory	keyword	/home/ubuntu/peat/	The working directory of the process.
process.thread.id	long	140447875082048	ID of the thread the log event originated from.
process.thread.name	keyword	MainThread	Name of the thread the log event originated from.
observer.hostname	keyword	WORKSTATION-1	Hostname of the system the log event originated from.
observer.ip	keyword	[‘127.0.0.1’, ‘172.17.0.3’]	Array of IP addresses present on the host the log event originated from.
observer.mac	keyword	00:00:00:11:22:33	Array of MAC addresses present on the host the log event originated from.
observer.interface.name	keyword	[‘lo’, ‘eth0’]	Array of names of network interfaces on the host the log event originated from.
observer.os.family	keyword	ubuntu, debian, windows	OS family, such as redhat, debian, freebsd, or windows.
observer.os.full	keyword	Linux 5.0.0-20-generic (Ubuntu 19.04)	Full information on the system OS.
observer.os.name	keyword	Windows	General name of the OS.
observer.os.version	keyword	19.04	Operating system version as a raw string.
observer.geo.city_name	keyword	Albuquerque	Name of the city where the device is physically located.
observer.geo.country_name	keyword	USA	Name of the country where the device is physically located, in whatever form is reasonable.
observer.geo.location	geo_point	{‘lon’: -3.000000, ‘lat’: 45.000000}	Longitude and latitude of the device’s physical location.
observer.geo.name	keyword	some-city, 1st floor network closet	Custom location as retrieved from the device.
observer.geo.timezone	keyword	America/Denver	Timezone of the system.
user.name	keyword	ubuntu	Name of the user running the tool.
peat.containerized	boolean	True	If PEAT was run as a container (Docker/Podman).
peat.debug_level	long	2	Current debugging level of PEAT
peat.entrypoint	keyword	CLI	How PEAT was executed (the entrypoint). Possible values: CLI, Package, REST API
peat.podman	boolean	False	If PEAT was run as a container in Podman.
peat.python_version	keyword	3.6.7	The version of Python used to execute PEAT.

8.10.6. OT Devices (ot-device-hosts-timeseries-*)

OT field device information collected by PEAT.

8.10.6.1. Notes

• Index: ot-device-hosts-timeseries-<date>, where date is, year.month.day in UTC. Example: ot-device-hosts-timeseries-2026.01.29 (for data collected on Jan 29th, 2026)

• message: Human-readable description or summary of the device.

• Every entry includes the Base Fields and Agent Fields.

• All fields are nested under the host field, e.g. host.ip.

• Nested and custom fields attempt to follow the ECS field set names where possible.

• Events that occur on the host and pertain to active status information, e.g. device power on/reset, service up, logic changed, etc, will be put into the ot-device-events-* index

• Some status attributes, such as system uptime, can be derived from device events or logs.

8.10.6.2. Fields

Note

The host.extra field has sub-fields dynamically named based on the PEAT device module name (e.g. host.extra.selrelay.*), which does not conform to ECS. This is to prevent clashes with a dynamically defined schema. Example: you push a bunch of data from SEL, and a field (say, address) happens to have the same name as a ION field. If the SEL address was a integer, but the ION is a string, when PEAT tries to push the ION data it will fail due to a different data type for the same field name.

OT Devices Fields

Field	Data Type	Example(s)	Description
host.architecture	keyword	mips	Architecture of the device CPU, if known.
host.hostname	keyword	relay-1.local	Hostname of the device (if resolved). In the case of a device with multiple communication modules, this is the hostname of the module PEAT primarily uses to communicate (or first discovered).
host.id	keyword	West-relay-1223423	Unique identifier for the device. Can be anything, as long as it’s consistent.
host.ip	ip	192.0.2.36	IP address of the device. In the case of a device with multiple communication modules, this is the IP address of the module PEAT primarily uses to communicate (or first discovered).
host.mac	keyword	00:00:00:11:22:33	MAC address of the device. In the case of a device with multiple communication modules, this is the MAC address of the module PEAT primarily uses to communicate (or first discovered).
host.serial_port	keyword	COM8	Serial port on the local system connected to the device. This could be a Windows COM port, e.g. COM4, or a Linux file path, e.g. /dev/ttyS0. This is also used for USB connections. To get the specific serial settings, lookup the interface with the matching port in interface.
host.name	keyword	relay-1	Name to refer to the device as, e.g. as pulled from a config or resolved via DNS.
host.part_number	keyword	0700G12B1B1B7281A468	Part number of the device, as defined by the vendor and stored on the device.
host.type	keyword	PLC, Power Meter	The class of device, e.g. PLC, Relay, RTU, Controller (catch-all), etc.
host.serial_number	keyword	1877625	Unique serial number of the device.
host.manufacturing_date	date	2016-02-11:11:22:33	When the device was manufactured (physically created).
host.run_mode	keyword	PROG, RUN	Run mode of the device. For example, on a PLC, there may be a key in the front of the device that sets PROG or RUN (program vs running). What this field means depends on the device, for instance a PLC’s potential run modes will differ from a RTU’s potential run modes.
host.slot	keyword	1	Position of the device in a rack or larger device. This can be a relative position, e.g. ‘0’ for the first module in a PLC, or a name or other identifier for the position (such as an internal bus address).
host.start_time	date	2016-02-11:11:22:33	UTC timestamp of when the device last powered on.
host.status	keyword	some_status	Status of the device. The meaning of this field is device-dependant.
host.uptime	long	112442424	Seconds the host has been up (powered on/online).
host.module	host	{…}	Physical add-on modules in a device, e.g. slots in a PLC or rack. These also include add-on components, such as a wireless radio. These can include analog and digital I/O modules, COMMs modules (Ethernet, various serial protocols, Wi-Fi, LTE, etc.), CPU modules, and anything else really. The fields are the same as host.*, and modules may be further nested (e.g. a module may itself have modules).
host.extra	flattened	{…}	Additional vendor/model-specific information that doesn’t fit into any of the other fields. module is the tool pushing the data. In PEAT, this would be the lowercase name of the device module, e.g. m340.
host.description.brand	keyword	ControlLogix, PowerLogic ION	Brand of the device. Can be empty if not applicable e.g. most SEL devices.
host.description.description	text	this PLC is used for controlling Process A	Free-form description of the device, such as a ‘description’ configuration value extracted from the device or other general information that is useful to note.
host.description.full	keyword	Schneider Electric PowerLogic ION 8650A	Combination of vendor, brand, model, sub_model, and any other identifiers. Used to perform lookups with fuzzy string matching.
host.description.full.text	text	Schneider Electric PowerLogic ION 8650A	Same content as full, just indexed as text. This enables searching arbitrary words that are a part of the field, e.g. ‘Allen-Bradley’ or ‘S7-1200’. This is implemented as a Elasticsearch Multi-Field.
host.description.model	keyword	8650A	Model of the device.
host.description.product	keyword	PowerLogic ION 8650A	The product identifier for the device, minus the vendor. This is includes the brand and model.
host.description.product.text	text	SIPROTEC 4 7SJ64	product indexed as text in Elasticsearch instead of keyword.
host.description.vendor.name	keyword	Schweitzer Engineering Laboratory	The full expanded vendor name. Used for display in a visualization or dashboard.
host.description.vendor.id	keyword	SEL	Abbreviated version of the vendor name that can be used for lookups.
host.event.action	keyword	device-config-change	What happened in the event.
host.event.category	keyword	host	ECS category of the event, out of the allowed values defined by ECS. This is usually host for PEAT data. Further reading in the ECS documentation
host.event.created	date	2016-02-11:11:22:33	When the event occurred.
host.event.dataset	keyword	metering_reads	What log the event came from. Especially important on devices with multiple log types.
host.event.extra	flattened	{…}	Other event metadata (this field is not well defined yet)
host.event.geo.timezone	keyword	America/Denver	Timezone should be populated when the event’s timestamp does not include timezone information already (e.g. default Syslog timestamps). It’s optional otherwise. Acceptable timezone formats are: a canonical ID (e.g. Europe/Amsterdam), abbreviated (e.g. EST) or an HH:mm differential (e.g. -05:00).
host.event.hash.md5	keyword	75926…	MD5 hash of raw event field (event.original) to be able to demonstrate log integrity
host.event.hash.sha1	keyword	50CD3…	SHA1 hash of raw event field (event.original) to be able to demonstrate log integrity
host.event.hash.sha256	keyword	5702F…	SHA 256 hash of raw event field (event.original) to be able to demonstrate log integrity
host.event.hash.sha512	keyword	B19FC…	SHA 512 hash of raw event field (event.original) to be able to demonstrate log integrity
host.event.ingested	date	2016-02-11:11:22:33	When the event was generated by PEAT, e.g. when it was parsed or pulled from a device. This should almost always differ from ‘created’ and the two should NOT be confused.
host.event.kind	keyword	event	Gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. Further reading in the ECS documentation.
host.event.message	text	Some message	Simplified message body, for example a human-readable portion of the raw event. This should be set in addition to setting the original field.
host.event.module	keyword	SELRelay	Name of the module this data is coming from, e.g. the PEAT module.
host.event.original	keyword	Power on	Original raw text of the log entry.
host.event.outcome	keyword	success	Outcome of the event. Must be one of: success, failure, unknown. Further reading in the ECS documentation.
host.event.reason	keyword	IPv4 address in device configuration differed from previous known value	Reason why this event happened. This describes the why of a particular action or outcome captured in the event. Where event.action captures the action from the event, event.reason describes why that action was taken. For example, a web proxy with an event.action which denied the request may also populate event.reason with the reason why (e.g. blocked site).
host.event.provider	keyword	192.0.2.36	Source of the event. This is almost always the Device ID.
host.event.sequence	long	8	Sequence number of the event. The sequence number is a value published by some event sources, to make the exact ordering of events unambiguous, regardless of the timestamp precision.
host.event.severity	keyword	debug	Severity or log level of the event as stored on the device.
host.event.type	keyword	[change, error]	List of event category ‘sub-buckets’ the alert falls under. For example, an alert regarding a device configuration change would have change as a value. Valid values: access, change, creation, deletion, end, error, info, installation, start. Further reading in the ECS documentation.
host.firmware.checksum	keyword	12345	Checksum used by the device to verify the firmware image is valid.
host.firmware.extra	flattened	{…}	Additional unstructured information related to the firmware, generally vendor-specific information such as ‘settings_version’.
host.firmware.file.created	date	2016-02-11:11:22:33	File creation time
host.firmware.file.device	keyword	relay-louie	Device that is the source of the file. If this is a static parse, then it should be the name of the system the file was recovered from or parsed on. Otherwise, this should be the ID of the device it was pulled from.
host.firmware.file.directory	keyword	/home/ubuntu/	Path to directory where the file is located.
host.firmware.file.extension	keyword	dpk	File extension of the firmware image file as stored on the device or loaded into parse, if known. Note: this does NOT include a . character.
host.firmware.file.path	keyword	/relay_1/SET_ALL.TXT	Path of the file, either on disk or on the device
host.firmware.file.local_path	keyword	/home/myuser/peat_results/relay_1/SET_ALL.TXT	Path of the file, in it’s original form. This may be either the path to the file on the device, or the path from the system it originated from (e.g. as extracted from a project file or using PEAT Pillage).
host.firmware.file.group	keyword	ubuntu	File’s owning group, if known.
host.firmware.file.mime_type	keyword	application/gzip	MIME type should identify the format of the file or stream of bytes using IANA official types, where possible. When more than one type is applicable, the most specific type should be used.
host.firmware.file.mtime	date	2016-02-11:11:22:33	Last time the file content was modified
host.firmware.file.name	keyword	1234.dpk	Name including extension of the firmware image file as stored on the device or loaded into parse, if known.
host.firmware.file.owner	keyword	SomeUser	File owner’s username of the firmware image file as stored on the device or loaded into parse, if known. This applies to files provided to peat parse, and we’ve also seen this with a project file pulled from a device (M340).
host.firmware.file.size	long	4096	Firmware image size in bytes. Only relevant when file.type is ‘file’.
host.firmware.file.type	keyword	file	Firmware image file type: file, dir, or symlink. This is usually file, though there may (likely) be exceptions to this in the future, hence it’s inclusion.
host.firmware.file.hash.md5	keyword	75926…	MD5 hash of the firmware image file. Only relevant when file.type is ‘file’.
host.firmware.file.hash.sha1	keyword	50CD3…	SHA1 hash of the firmware image file. Only relevant when file.type is ‘file’.
host.firmware.file.hash.sha256	keyword	5702F…	SHA 256 hash of the firmware image file. Only relevant when file.type is ‘file’.
host.firmware.file.hash.sha512	keyword	B19FC…	SHA 512 hash of the firmware image file. Only relevant when file.type is ‘file’.
host.firmware.hash.md5	keyword	75926…	MD5 hash of the firmware image (the contents of the original). This may differ from the file hash, if present.
host.firmware.hash.sha1	keyword	50CD3…	SHA1 hash of the firmware image (the contents of the original). This may differ from the file hash, if present.
host.firmware.hash.sha256	keyword	5702F…	SHA 256 hash of the firmware image (the contents of the original). This may differ from the file hash, if present.
host.firmware.hash.sha512	keyword	B19FC…	SHA 512 hash of the firmware image (the contents of the original). This may differ from the file hash, if present.
host.firmware.id	keyword	SEL-351S-0-R000-V0-Z000000-D00000000	Firmware identification string, e.g. the FID or BFID strings in SEL devices.
host.firmware.last_updated	date	2016-02-11:11:22:33	The timestamp of when the firmware was last updated on the device.
host.firmware.original	binary	E1B0336271…	Base64-encoded full binary image of the device’s firmware.
host.firmware.revision	keyword	1	Revision of the device’s current firmware (or operating system). Common field seen on devices that’s sometimes distinct from the canonical version string.
host.firmware.release_date	date	2019-01-11:00:00:00	The release date of the firmware.
host.firmware.timestamp	date	2015-05-28:07:05:50	Timestamp as extracted from the device or firmware, device-dependent meaning. Often represents when the firmware was compiled/built or released.
host.firmware.version	keyword	2.6	Version of the device’s current firmware (or operating system).
host.boot_firmware.*	N/A	N/A	This field stores information about the devices boot firmware (what it uses to boot up). It uses the same fields as host.firmware.
host.geo.city_name	keyword	Albuquerque	Name of the city where the device is physically located.
host.geo.country_name	keyword	USA	Name of the country where the device is physically located, in whatever form is reasonable.
host.geo.location	geo_point	{ ‘lon’: -73.000000, ‘lat’: 45.000000 }	Longitude and latitude of the device’s physical location.
host.geo.name	keyword	some-city, 1st floor network closet	Custom location as retrieved from the device.
host.geo.timezone	keyword	America/Denver	Timezone configured on the device.
host.hardware.id	keyword	33234SLDKSJ	Hardware ID of the device
host.hardware.storage_available	long	572896	Amount of persistent storage currently available on the device
host.hardware.storage_usage	long	201264	Amount of persistent storage currently in use on the device
host.hardware.storage_total	long	774160	Total amount of storage on the device
host.hardware.storage_type	keyword	hdd	Type of storage on the device, lowercase and underscore-separated (e.g. hdd, ssd, nvram)
host.hardware.memory_available	long	572896	Amount of volatile memory (e.g. RAM) currently available
host.hardware.memory_usage	long	201264	Amount of volatile memory (e.g. RAM) currently in use
host.hardware.memory_total	long	774160	Total amount of volatile memory (e.g. RAM) on the device
host.hardware.memory_type	keyword	ddr2_sdram	Type of volatile memory on the device, lowercase and underscore-separated (e.g. ddr2_sdram)
host.io.address	keyword	29	Address of the I/O point (if applicable)
host.io.description	text	some tag description	Human-readable description of the I/O point
host.io.direction	keyword	input	Direction of the I/O point. Possible values: input, output
host.io.id	keyword	O0	ID of the I/O point.
host.io.name	keyword	fuel-rtu-1_I16	I/O point name or label (typically referenced by a tag)
host.io.type	keyword	analog	Data type of the I/O point. Possible values: analog, binary
host.io.slot	keyword	1	Slot number(s) of the module(s) the point is associated with, if any
host.interface.application	keyword	modbus	Higher-level communication protocol being used regardless of whether the device is connected via serial or IP.
host.interface.connected	boolean	true	If the interface is currently connected to something (e.g. carrier signal on Ethernet or connected to a tower for wireless interfaces)
host.interface.description	Description	…	Identifying information for the interface’s hardware or software, such as vendor, brand, and model. uses the same fields as host.description.*.
host.interface.enabled	boolean	true	If the interface is enabled in the device’s configuration.
host.interface.extra	flattened	{…}	Additional unstructured information related to the interface, generally this is vendor-specific information.
host.interface.name	keyword	port_f	Interface name, as defined by the device. Example: SEL refers to the serial and network ports by names such as 1, 2, 3, F, etc.
host.interface.type	keyword	ethernet	The type of physical communication medium the communication interface utilizes. Lowercase, underscore separators, e.g. ‘rs_422’.
host.interface.hostname	keyword	relay2-backup.local	Hostname of the network interface (if resolved).
host.interface.mac	keyword	00:00:00:00:00:00	The IEEE 802 standard 48-bit MAC address of the interface. Only applicable to Ethernet-type interfaces. Note: this is a keyword -type per Elastic’s guidance.
host.interface.mtu	long	1500	Maximum Transmission Unit (MTU) size configured for the interface. This generally only applies to Ethernet interfaces.
host.interface.promiscuous_mode	boolean	true	If the interface is in Promiscuous Mode (passive capture).
host.interface.speed	long	1000	Transmission rate of the interface, in Mbps (megabits per second). Example: for Gigabit Ethernet, this would be 1000.
host.interface.uptime	long	23345	How long the interface has been connected, in milliseconds.
host.interface.id	keyword	Port 3	Identifier for the interface. The meaning of this value is device-dependent.
host.interface.ip	ip	192.0.2.1	The Internet Protocol (IP) version 4 address of the interface. This is usually applicable to Ethernet-type interfaces, but could be applicable to serial interfaces as well.
host.interface.subnet_mask	ip	255.255.255.0	IPv4 subnet mask of the interface, in standard dotted-decimal notation.
host.interface.gateway	ip	192.0.2.254	IPv4 address of the default gateway of the interface, in standard dotted-decimal notation.
host.interface.serial_port	keyword	/dev/ttyS0	Serial port on the local system connected to the device. This could be a Windows COM port, e.g. COM4, or a Linux file path, e.g. /dev/ttyS0. This is also used for USB connections.
host.interface.baudrate	integer	56700	Data rate of the serial link. Only applicable to serial interfaces.
host.interface.data_bits	byte	8	Number of data bits for a serial link. Only applicable to serial interfaces.
host.interface.parity	keyword	none	Parity setting for the serial link. Only applicable to serial interfaces. Typical values: none, even, odd
host.interface.stop_bits	byte	0	Number of stop bits for the serial link. Only applicable to serial interfaces.
host.interface.flow_control	keyword	none	Flow control setting for the serial link. Only applicable to serial interfaces. Typical values: none, rts/cts
host.interface.services	flattened	{…}	Services associated with the interface. Refer to the host.service.* fields for details on the fields of each service.
host.interface.version	keyword	1.2.3	Version of the interface’s firmware or software.
host.logic.author	keyword	Killroy	Name of the person/organization/program that wrote the logic
host.logic.description	keyword	Some description	Description for the logic or project file
host.logic.description.text	text	Some description	Same content as host.logic.description, indexed as text type. This enables searching arbitrary words that are a part of the field.
host.logic.file.created	date	2016-02-11:11:22:33	File creation time
host.logic.file.device	keyword	relay-louie	Device that is the source of the file. If this is a static parse, then it should be the name of the system the file was recovered from or parsed on. Otherwise, this should be the ID of the device it was pulled from.
host.logic.file.directory	keyword	/home/ubuntu/	Path to directory where the file is located.
host.logic.file.extension	keyword	dpk	File extension of the logic file as stored on the device or loaded into parse, if known. Note: this does NOT include a . character.
host.logic.file.path	keyword	/relay_1/SET_ALL.TXT	Path of the file, either on disk or on the device
host.logic.file.local_path	keyword	/home/ubuntu/peat_results/relay_1/SET_ALL.TXT	Path of the file, in it’s original form. This may be either the path to the file on the device, or the path from the system it originated from (e.g. as extracted from a project file or using PEAT Pillage).
host.logic.file.group	keyword	ubuntu	File’s owning group, if known.
host.logic.file.mime_type	keyword	application/gzip	MIME type should identify the format of the file or stream of bytes using IANA official types, where possible. When more than one type is applicable, the most specific type should be used.
host.logic.file.mtime	date	2016-02-11:11:22:33	Last time the file content was modified
host.logic.file.name	keyword	1234.dpk	Name including extension of the logic file as stored on the device or loaded into parse, if known.
host.logic.file.owner	keyword	SomeUser	File owner’s username of the logic file as stored on the device or loaded into parse, if known. This applies to files provided to peat parse, and we’ve also seen this with a project file pulled from a device (M340).
host.logic.file.size	long	4096	Logic size in bytes. Only relevant when file.type is ‘file’.
host.logic.file.type	keyword	file	Logic file type: file, dir, or symlink. This is usually file, though there may (likely) be exceptions to this in the future, hence it’s inclusion.
host.logic.file.hash.md5	keyword	75926…	MD5 hash of the logic file.
host.logic.file.hash.sha1	keyword	50CD3…	SHA1 hash of the logic file.
host.logic.file.hash.sha256	keyword	5702F…	SHA 256 hash of the logic file.
host.logic.file.hash.sha512	keyword	B19FC…	SHA 512 hash of the logic file.
host.logic.formats	nested	{‘tc6’: ‘<…>’}	Sub-formats the logic has been parsed into, such as structured_text" or "tc6". Device dependent.”
host.logic.hash.md5	keyword	75926…	MD5 hash of the raw logic (the contents of the original). This may differ from the file hash, if present.
host.logic.hash.sha1	keyword	50CD3…	SHA1 hash of the raw logic (the contents of the original). This may differ from the file hash, if present.
host.logic.hash.sha256	keyword	5702F…	SHA 256 hash of the raw logic (the contents of the original). This may differ from the file hash, if present.
host.logic.hash.sha512	keyword	B19FC…	SHA 512 hash of the raw logic (the contents of the original). This may differ from the file hash, if present.
host.logic.id	keyword	142342SERU	Project ID or a similar identifier for the logic, e.g. a machine-generated UUID for the logic stored by the device.
host.logic.last_updated	date	2016-02-11:11:22:33	UTC timestamp of when the logic was last updated on the device.
host.logic.name	keyword	project-1	Project name or other such identifier for the logic, e.g. a human-readable name for the logic stored by the device
host.logic.original	text	CHUTES: AND LATTERS	Unparsed device program logic, in whatever format makes sense for that device. It is the file(s) that make up the process state logic, e.g., the ladder logic on a PLC or the configured protection schemes on a substation relay.
host.logic.parsed	text	CHUTES: AND LATTERS	Complete parsed device program logic, in whatever format makes sense for that device. It is the file(s) that make up the process state logic, e.g., the ladder logic on a PLC or the configured protection schemes on a substation relay.
host.memory.address	keyword	0x4000FFFF	Address in memory of the read (the location).
host.memory.created	date	2016-02-11:11:22:33	When the read occurred. Represents when in time the memory address had the value.
host.memory.dataset	keyword	watchdog_log	Memory region or source the read is associated with, if applicable.
host.memory.device	keyword	relay-louie	Source of the read. This is almost always the device ID.
host.memory.value	keyword	0xFFFFFFFF	The value read from memory, as a hexadecimal string.
host.memory.extra	flattened	{…}	Additional data or metadata about the memory read.
host.os.family	keyword	linux	OS family (such as redhat, debian, freebsd, windows).
host.os.full	keyword	WindRiver VxWorks 7	Operating system name, including the version or code name.
host.os.kernel	keyword	4.4.0-112-generic	Operating system kernel version as a raw string.
host.os.name	keyword	VxWorks	Operating system name, without the version.
host.os.timestamp	date	2015-05-28:07:05:50	Timestamp as extracted from the device or firmware, device-dependent meaning. Often represents when the OS was compiled/built or released.
host.os.vendor.name	keyword	Wind River Systems	The full name of the vendor of the OS, if known.
host.os.vendor.id	keyword	WindRiver	Abbreviated vendor of the OS, if known.
host.os.version	keyword	7	Operating system version as a raw string.
host.registers.address	keyword	23, 24112016, pump-jack-six	Address of the data. Tells protocol parser how to identify a data field in a packet. A number string, or more complex identifier. For Object Oriented (OO) protocols, this field flattens the data_address. BACNET example: ObjectType_InstanceNumber_PropertyIdentifier_[Fixed structure for each property type]
host.registers.data_type	keyword	float_16	Data type of the register. Tells parser how to interpret the field.
host.registers.description	text	Intake Fuel - Valve 1 - Second Boiler	Human-readable description of the register (some device configurations or project files have this).
host.registers.extra	flattened	{…}	Additional metadata for the register
host.registers.measurement_type	keyword	analog	Type of information the register is tracking (e.g analog I/O, Discrete I/O). Tells analytic which algorithms to deploy. For example, in Modbus a 16-bit register can track an event count (Discrete), a temperature (analog), or could be a set of 16 Boolean flags (alarms).
host.registers.protocol	keyword	dnp3	The Parser uses this to distinguish protocols. Not all vendors follow the protocol spec. Indicate if this is a vendor deviation from the standard using the syntax [protocol]_[device or vendor name].
host.registers.read_write	keyword	read_write	Direction of information flow. Is register read, write, or both? Possible values: read, write, read_write
host.registers.tag	keyword	valve_1	Register tag given in config file. Provides analytic with some register context. May be a human-readable display name.
host.related.emails	keyword	example@example.com	Any email addresses related to the device or users on the device
host.related.files	keyword	config.xml	Any files found on the device or referenced from the device’s configuration. These can either be absolute paths or just filenames. Absolute paths are preferred, if known.
host.related.hash	keyword	75926…	Any hashes related to the device or interface
host.related.hosts	keyword	relay-1	Any hostnames or names related to the device or interface
host.related.ip	keyword	192.168.0.1	Any IP addresses related to the device or interface
host.related.mac	keyword	00:A0:C9:14:C8:29	Any MAC addresses related to the device or interface
host.related.ports	long	80, 443, 20000	TCP or UDP ports related to the device or interface
host.related.protocols	keyword	bacnet, modbus_tcp, dnp3, ftp	Application layer (OSI Layer 7) protocols related to a device or interface
host.related.roles	keyword	admin, operator	Authentication roles, e.g. ‘admin’ or ‘operator’
host.related.urls	keyword	https://example.com/example	URLs related to the device or found on the device
host.related.users	keyword	Administrator	Any usernames related to the device or interface. Examples: users that logged into a service or users configured on the device.
host.service.enabled	boolean	true	If the service is enabled in the device configuration. NOTE: do not assume this matches the status!
host.service.extra	flattened	{…}	Additional information about the service, such as a banner grab, odd behavior, or other miscellaneous data
host.service.port	long	502	Port the service is listening on (for TCP/IP transports).
host.service.protocol	keyword	modbus_tcp	Protocol of the service. Lowercase, underscore separators.
host.service.protocol_id	keyword	10	Unique protocol identifier for the device, e.g. BACnet device identifier (‘BACnet ID’) or Modbus slave ID.
host.service.role	keyword	dnp3_master	The operational role of the device for a given protocol.
host.service.status	keyword	verified	State of the service. Valid values: open, closed, verified, and ". verified: service was used to positiviely identify the device (e.g. this is a SEL 351S) and the service. open: something is listening	though it may not be the named service. closed: port is not able to be accessed. NOTE: verified means verified over the a live connection	not just read from a configuration file. Instead	the enabled field should be used to store the configuration.”
host.service.transport	keyword	udp	OSI Layer 4 transport protocol. Typical possible values: udp, tcp
host.ssh_keys.description	keyword		Description of the SSH key and/or any comments
host.ssh_keys.description.text	text		Text-mapped field for host.ssh_keys.description
host.ssh_keys.file.*	nested		The file associated with the key, if any. This has the same file.* fields as for other host fields.
host.ssh_keys.host	keyword	example.com	Host associated with the key (hostname, DNS name, or IP).
host.ssh_keys.id	keyword		Unique identifier for the key, if any
host.ssh_keys.original	keyword		Complete contents of the key, with any trailing whitespace removed
host.ssh_keys.original.text	text		Text-mapped field for host.ssh_keys.original
host.ssh_keys.type	keyword	public, private	Type of key, either public or private
host.ssh_keys.user	keyword	bob	Name of user associated with the key
host.tag.address	keyword	29	Address of the tag.
host.tag.description	keyword	some tag description	Human-readable description of the tag.
host.tag.description.text	text	some tag description	Same as above, but parsed as Elasticsearch text type.
host.tag.io	keyword	rtu-8_I0	I/O point it’s attached to (e.g. protocol register or physical I/O).
host.tag.name	keyword	var_rtu-8_I0	Tag name or label (e.g. how it’s referenced).
host.tag.type	keyword	analog	Data type of the tag. Typical possible values: analog, binary
host.users.description	keyword		General description of the user (this is open to interpretation)
host.users.description.text	text		Text-mapped field for host.users.description
host.users.domain	keyword		Name of the domain the user is a member of
host.users.email	keyword	example@example.com	User email address
host.users.full_name	keyword	Billy Bob Joe	The user’s full name, if known
host.users.full_name.text	text		Text-mapped field for host.users.full_name.text
host.users.id	keyword	bob_1	Unique identifier of the user
host.users.name	keyword	bob	Short name or login of the user
host.users.name.text	text		Text-mapped field for host.users.name.text
host.users.permissions	keyword	Login, Web	Permissions the user has available
host.users.roles	keyword	Administrator, User	The user’s roles, as strings
host.users.extra	flattened	{…}	Additional data or metadata about the user. This also includes unstructured raw data from the device that may be relevant.

8.10.7. PEAT scan summaries (peat-scan-summaries-*)

Results from PEAT scans.

8.10.7.1. Notes

Index: peat-scan-summaries-<date>, where date is, year.month.day in UTC. Example: peat-scan-summaries-2026.01.01 - Every entry includes the Base Fields and Agent Fields.

8.10.7.2. Fields

Scan Summary Fields

Field	Data Type	Example(s)	Description
peat_version	keyword	2.0.1.20210930	Version of PEAT that performed the scan, if applicable
peat_run_id	keyword	162493555659	ID of the PEAT run for this scan. This is the value of agent.id in Elasticsearch. Used for associating other artifacts (e.g. device files) with this particular scan.
scan_duration	double	5.114307479001582	Approximate time the scan took, in seconds
scan_modules	keyword	SELRelay	PEAT device modules used to perform the scan
scan_type	keyword	unicast_ip	Type of scan. serial, unicast_ip, or broadcast_ip.
scan_targets	keyword	192.0.2.0/24	Targets used by the scan. These are the actual targets used after PEAT has parsed them into usable targets and removed duplicates.
scan_original_targets	keyword	['eth1', '192.0.2.255', '10.1.2.255/24']	Original arguments used for the scan. This is the targets as provided by the user prior to PEAT parsing them into usable targets and removing duplicates.
num_hosts_active	long	1	Number of hosts that responded, regardless of verification status
num_hosts_online	long	1	Number of hosts that responded but were not verified
num_hosts_verified	long	1	Number of hosts that were verified
hosts_online	ip	192.0.2.36	IDs of hosts that responded. Note: this does NOT include verified hosts!
hosts_verified	nested	{…}	Information from hosts that were successfully verified

8.10.8. PEAT pull summaries (peat-pull-summaries-*)

Results from PEAT pulls.

8.10.8.1. Notes

Index: peat-pull-summaries-<date>, where date is, year.month.day in UTC. Example: peat-pull-summaries-2026.01.01 - Every entry includes the Base Fields and Agent Fields.

8.10.8.2. Fields

Pull Summary Fields

Field	Data Type	Example(s)	Description
peat_version	keyword	2.0.1.20210930	Version of PEAT that performed the pull, if applicable
peat_run_id	keyword	162493555659	ID of the PEAT run for this pull. This is the value of agent.id in Elasticsearch. Used for associating other artifacts (e.g. device files) with this particular pull.
pull_duration	double	5.114307479001582	Approximate time pull took, in seconds
pull_modules	keyword	SELRelay	PEAT device modules used to perform the pull
pull_targets	keyword	192.0.2.0/24	Targets used by the pull. These are the actual targets used after PEAT has parsed them into usable targets and removed duplicates.
pull_original_targets	keyword	['eth1', '192.0.2.255', '10.1.2.255/24']	Original arguments used for the pull. This is the targets as provided by the user prior to PEAT parsing them into usable targets and removing duplicates.
pull_devices	keyword	192.0.2.36	Devices that were pulled from. Note that this may differ from pull_targets based on the results of scanning and/or de-duplication.
pull_comm_type	keyword	unicast_ip	Type of pull. serial, unicast_ip, or broadcast_ip.
num_pull_results	long	1	Number of hosts that were pulled from
pull_results	nested	{…}	Data of hosts that were pulled, with some fields excluded (such as binary blobs)

8.10.9. PEAT parse summaries (peat-parse-summaries-*)

Results from PEAT parses.

8.10.9.1. Notes

Index: peat-parse-summaries-<date>, where date is, year.month.day in UTC. Example: peat-parse-summaries-2026.01.01 - Every entry includes the Base Fields and Agent Fields.

8.10.9.2. Fields

Parse Summary Fields

Field	Data Type	Example(s)	Description
peat_version	keyword	2.0.1.20210930	Version of PEAT that performed the parse, if applicable
peat_run_id	keyword	162493555659	ID of the PEAT run for this parse. This is the value of agent.id in Elasticsearch. Used for associating other artifacts (e.g. device files) with this particular parse.
parse_duration	double	5.114307479001582	Approximate time parse took, in seconds
parse_modules	keyword	SELRelay	PEAT device modules used to perform the parse
input_path	keyword	/devices/	Original argument to the parse
files_parsed	keyword	/devices/set_all.txt	Files that were parsed
num_files_parsed	long	1	Count of the files that were parsed
num_parse_successes	long	1	Count of successful parses
num_parse_failures	long	1	Count of failed parses
parse_failures	nested	{…}	Results of failed parses
parse_results	nested	{…}	Results of successful parses

8.10.10. References

• ECS Reference

• ECS Conventions

• ECS Guidelines

• ECS Changelog

• Field Datatypes

• Multi-Fields

• Elasticsearch Documentation

8.10.11. Examples/further reading

• Filebeat ECS fields

• Packetbeat ECS fields

• Winlogbeat ECS fields

• Punch platform ECS example