Glossary

Attribute

A key-value pair associated with a Modality entity. Most Modality entities can have attributes, notably events, timelines, and workspaces. Attributes are a core part of the Modality data model, letting you store and manage arbitrary data in a structured way. Event attributes commonly contain either system runtime information or metadata useful for managing and organizing the events. For example, an event fired by a sensor might have a payload attribute to report the runtime sensor reading value, as well as a subsystem attribute, allowing you to lump it together with all other events from its subsystem for analysis. In Conform, you can leverage these attributes to write detailed specifications for how your system should behave.

Event

Unit of information collected by Modality and used to build a trace of system execution. Events and the relationships between them are the basic building blocks of Conform specifications. Every event must be associated with a single timeline. Events can have any number of attributes to report system data or event metadata.

Logical Time

Use of clocks based on ordering rather than actual wall-clock time. Logical time values only mean anything in relation to each other. If event a was recorded at logical time 1 and event b was recorded at logical time 3, we know a happened before b. Differently to wall-clock time, though, logical time doesn't necessarily tell us how much earlier a was than b. Logical time is a key concept in Conform specifications, as event relationships are based on logical time unless explicitly written otherwise.

modalityd

Modality's daemon which receives system data, builds a trace of overall system execution, and serves trace data to various clients. The Conform CLI must have a connection to modalityd correctly configured, as all Conform operations are run against data managed by modalityd. This connection is configured with the conform config command.

Interaction

Record of a causal link between timelines. Every time a timeline communicates with another, the sending timeline could have influenced the behavior on the receiving timeline. Modality's interactions allow Conform to trace causal connections between timelines, enabling you to write specifications with event patterns across timelines.

Segment

A subset of the data in a workspace, generated automatically by Modality according to a segmentation rule in the workspace definition file (opens new window). Segments let you automatically chunk up your data based on timeline attributes. One example use case for segments is to separate runs of your system—you could have a workspace for all the data collected from a given test rig segmented by run_id, automatically creating a segment for each discrete run of your system.

Specification

An executable test case which can be run against any part of your system's recorded execution. Specifications let you describe how your system should behave, including nominal, recovery, and prohibited behavior. For an example based on an autonomous drone, you could say that, whenever the "landing" command is observed, nominal behavior is for the drone to perform a successful landing (i.e. the "landing command" event is followed by the "successful landing" event). You could also include a recovery case, specifying that an "emergency landing" event is an acceptable outcome if the system needs to remedy some error. Specifications can describe all kinds of complex system behavior—see the SpeQTr reference (opens new window) for more information.

Time Domain

Analysis of signals and events with respect to wall clock time. This is in contrast to the logical clocks that Conform uses which are not associated with wall clock time but rather with the sequence of events. Because clocks drift, wall clock time can only be used in Conform for timelines which are in the same time domain, i.e. which use the same clock.

Timeline

A sequence of events with a specific ordering. Timelines are flexible, so mapping your system to a set of timelines is up to you. A timeline essentially just needs to be a source of events that you know will be in order. For a desktop application you might have a timeline for each thread. In an embedded system, each microcontroller could be a timeline. Timelines have attributes which you can use to filter them when defining workspaces and segments.

Workspace

View onto Modality's database that only consists of a certain subset of the data. Since Modality's database contains all data you have ever collected, workspaces are necessary to ensure you ask questions of the appropriate set of data. You define workspaces with a workspace definition file (opens new window), selecting which timelines should be included. In addition, you can automatically split your workspace into segments based on rules in your workspace definition.