You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/architecture/trace_file_mcap_format.adoc
+39-38Lines changed: 39 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,54 +10,54 @@ endif::[]
10
10
- Message records must be written into `chunk records` for indexed files
11
11
- Only OSI top-level messages containing a timestamp field are permitted to be directly stored in MCAP channels
12
12
- Must contain only a single scenario with a unique global time
13
-
- A MCAP file is condidered a single dataset
13
+
- An MCAP file is considered a single dataset
14
14
15
15
== Schema
16
16
- `name` field: Full message type name, including package (e.g., `osi3.SensorData`)
17
17
- `encoding` field: Must be `protobuf`
18
18
- `data` field: String-encoded `google::protobuf::FileDescriptorSet` for the OSI top-level message
19
19
20
20
== Channel
21
-
- `message_encoding` field: Must be "protobuf"
21
+
- `message_encoding` field: Must be `protobuf``
22
22
- `metadata` field:
23
-
- Must include an `osi_version` key, specifying the OSI SemVer version of the OSI top-level message contained within the channel
24
-
- Must include a `protobuf` key, specifying the protobuf SemVer version used to create the OSI top-level message contained within the channel
25
-
- Should include a `description` key, explaining the data's origin and purpose in natural language.
23
+
** Must include an `osi_version` key, specifying the OSI SemVer version of the OSI top-level message contained within the channel
24
+
** Must include a `protobuf` key, specifying the protobuf SemVer version used to create the OSI top-level message contained within the channel
25
+
** Should include a `description` key, explaining the data's origin and purpose in natural language.
26
26
27
27
28
28
== Message
29
29
- `publish_time` field:
30
-
- Must reflect the timestamp of the stored OSI top-level message
31
-
- Must be in nanoseconds
30
+
** Must reflect the timestamp of the stored OSI top-level message
31
+
** Must be in nanoseconds
32
32
- `log_time` field: Must reflect the time when the message was enqueued for MCAP file addition
33
-
- Must reflect the timestamp of the stored OSI top-level message
34
-
- Must be in nanoseconds
33
+
** Must reflect the timestamp of the stored OSI top-level message
34
+
** Must be in nanoseconds
35
35
36
36
37
37
== File-wide Metadata
38
38
- Must include metadata with the name `versions` containing at least the following key-value pairs:
39
-
* `osi`: SemVer version of the minimum required OSI version
39
+
** `osi`: SemVer version of the minimum required OSI version
40
40
- Must include metadata with the name `asam_osi` containing at least the following key-value pairs:
41
-
* `zero_time`: ISO 8601 YYYYMMDDThhmmss.f formatted point in time representing the zero time of the scenario
42
-
* `timestamp`: ISO 8601 YYYYMMDDThhmmss.f formatted creation time of the file
41
+
** `zero_time`: ISO 8601 YYYYMMDDThhmmss.f formatted point in time representing the zero time of the scenario
42
+
** `timestamp`: ISO 8601 YYYYMMDDThhmmss.f formatted creation time of the file
43
43
- It is strongly recommended to include metadata with the name `asam_osi` containing the following key-value pairs:
44
-
* `description`: Short human-readable scenario description
45
-
* `creator`: csv of person or company (not tool) creating the file
46
-
* 'license' csv of spdx identifiers
47
-
* 'data_sources' csv of model, scenario player, etc.
48
-
- Additional custom metadata may be added, but it is recommended to add a category with the name `context` where the key represents a prefix and the value pointing to the specification of the metadate. This allows to add other (channel-wise) metadata with the stated prefix. Thus, it becomes clear what a metadata is about and where it is specified. The following examples are given:
49
-
- GAIA-X4PLC-AAD SHACL Shape
50
-
- Assume you want to embed the hdmap of a scenario in the MCAP file.
51
-
- The `context` category contains the key `GAIA-X4PLC-AAD-hdmap` with the value `https://github.com/GAIA-X4PLC-AAD/ontology-management-base/blob/main/hdmap/hdmap_shacl.ttl`
52
-
- A channel metadata contains the key `GAIA-X4PLC-AAD-hdmap` with the value of the hdmap data in the given SHACLE shape.
53
-
- openDrive Reference
54
-
- Assume you want to express that oncoming traffic passes on the right side of the road.
55
-
- The `context` category contains the key `openDrive` with the value `https://publications.pages.asam.net/standards/ASAM_OpenDRIVE/ASAM_OpenDRIVE_Specification/1.8.1/specification/index.html`
56
-
- A file metadata in a new metadata category with the arbitrary name `specification` contains the key `openDrive-road-rule` with the value `RHT`
57
-
- Cycle time variation of a sensor
58
-
- Assume you want to express the interface cycle time variation of a sensor.
59
-
- The `context` category contains the key `iso_23150` with the value` ISO 23150:2011`
60
-
- A channel containing `OSI3::SensorData` messages has metadata with the key `iso_23150-cycle-time-variation:` and the value `80`
44
+
** `description`: Short human-readable scenario description
45
+
** `creator`: csv of person or company (not tool) creating the file
46
+
** `license`` csv of spdx identifiers
47
+
** `data_sources` csv of model, scenario player, etc.
48
+
- Additional custom metadata may be added, but it is recommended to add a category with the name `context` where the key represents a prefix and the value pointing to the specification of the metadata. This allows to add other (channel-wise) metadata with the stated prefix. Thus, it becomes clear what a metadata is about and where it is specified. The following examples are given:
49
+
** GAIA-X4PLC-AAD SHACL Shape
50
+
*** Assume you want to embed the hdmap of a scenario in the MCAP file.
51
+
*** The `context` category contains the key `GAIA-X4PLC-AAD-hdmap` with the value `https://github.com/GAIA-X4PLC-AAD/ontology-management-base/blob/main/hdmap/hdmap_shacl.ttl`
52
+
*** A channel metadata contains the key `GAIA-X4PLC-AAD-hdmap` with the value of the hdmap data in the given SHACL shape.
53
+
** openDrive Reference
54
+
*** Assume you want to express that oncoming traffic passes on the right side of the road.
55
+
*** The `context` category contains the key `openDrive` with the value `https://publications.pages.asam.net/standards/ASAM_OpenDRIVE/ASAM_OpenDRIVE_Specification/1.8.1/specification/index.html`
56
+
*** A file metadata in a new metadata category with the arbitrary name `specification` contains the key `openDrive-road-rule` with the value `RHT`
57
+
** Cycle time variation of a sensor
58
+
*** Assume you want to express the interface cycle time variation of a sensor.
59
+
*** The `context` category contains the key `iso_23150` with the value` ISO 23150:2011`
60
+
*** A channel containing `OSI3::SensorData` messages has metadata with the key `iso_23150-cycle-time-variation:` and the value `80`
61
61
62
62
== Compression
63
63
- OSI-compliant tooling must support compression types: `none`, `lz4`, and `zstd`
When not using an optional field, the corresponding `_` delimiter must be omitted so that no double `_` is present.
74
+
When not using an optional field, the corresponding underscore delimiter must be omitted so that no double underscore is present.
75
75
76
76
[#tab-MCAP-file-naming-convention]
77
77
.MCAP file naming convention
@@ -87,21 +87,21 @@ When not using an optional field, the corresponding `_` delimiter must be omitte
87
87
88
88
89
89
|type
90
-
| Specifies contained the top-level message(s) and must be one of the following values:
90
+
| Specifies the type of the contained the top-level message(s) and must be one of the following values:
91
91
92
92
`sv` file contains only `SensorView` messages. +
93
93
`gt` file contains only `GroundTruth` messages. +
94
94
`hvd` file contains only `HostVehicleData` messages. +
95
95
`sd` file contains only SensorData` messages. +
96
-
`tc` file contains only `TrafficCommand` messages.+
97
-
`tcu` file contains only `TrafficCommandUpdate` messages.
98
-
`tu` file contains only `TrafficUpdate` messages.
99
-
`mr` file contains only `MotionRequest` messages.
100
-
`su` file contains only `StreamingUpdate` messages.
96
+
`tc` file contains only `TrafficCommand` messages.+
97
+
`tcu` file contains only `TrafficCommandUpdate` messages. +
98
+
`tu` file contains only `TrafficUpdate` messages. +
99
+
`mr` file contains only `MotionRequest` messages. +
100
+
`su` file contains only `StreamingUpdate` messages. +
101
101
`multi` file contains multiple, different types of of top-level messages (not including different channels of the same type).
102
102
103
103
|opt. suffix
104
-
|An optional suffix which may be used the same way like the optional prefix or be used to specify further details like the minimum required OSI version. May not contain any `_` characters.
104
+
|An optional suffix which may be used the same way as the optional prefix or be used to specify further details like the minimum required OSI version. May not contain any `_` characters.
105
105
106
106
107
107
|===
@@ -110,6 +110,7 @@ When not using an optional field, the corresponding `_` delimiter must be omitte
110
110
**Example**
111
111
112
112
The following list shows examples of valid OSI MCAP file names:
0 commit comments