Onboard data with Scout

Scout can investigate registered live data, preview historical CSV mappings, and govern the onboarding of business files or tables. The workflows share equipment and master-data identity while producing different outcomes.

Choose a data path

Data type	Start here	Scout outcome	Next system action
Continuous MQTT telemetry	Configure the connection and source points in DFS, then create an equipment check	Field investigation, meaning confirmation, and mapping suggestions	Receive data continuously through the DFS ingestion workflow
Exported historical telemetry CSV	Open Historical backfill preview in an equipment task	Preview of valid, duplicate, conflicting, and rejected rows	Arrange the governed import with the data integration owner
Business files or tables	Select New data onboarding in Scout	Profiling, identity decisions, dry run, and dataset version	Publish to the target business workflow after approval

Connect live MQTT telemetry

Prepare connection information

Confirm the broker address, topics, authentication, TLS requirements, message format, equipment identifier, event time, time zone, and field units with the source owner. Store credentials in the approved connection configuration.

Configure and inspect

1. Register or select a supported MQTT connection in DFS.
2. Verify that authorized topics return messages, then inspect event time, equipment identity, and message structure.
3. Register source points with the appropriate parser and confirm they are within the Scout task scope.
4. Create an equipment data check and run discovery.
5. Review vibration axes, temperature, battery, and other measurement fields individually.
6. Review the mapping suggestions, then validate, approve, and apply them through the project workflow.
7. Inspect subsequent readings and actual use by the target application.

Scout discovery scope

Scout discovers data from governed source points already registered in DFS. MQTT subscription, message parsing, and continuous ingestion are managed in the DFS connection configuration.

For an empty message stream, inspect broker access, topics, and publishing devices. When messages arrive without usable field definitions, add the format specification or configure a supported parser.

Preview historical CSV mappings

Expand Historical backfill preview in an equipment task. Use it to check asset identity, event time, and field mappings on a limited sample before a governed import.

File requirements

• UTF-8 CSV
• File size up to 128 KiB
• Up to 500 data rows, excluding the header
• Up to 16 measurement columns
• Equipment ID, event ID, and event-time columns
• Event time in ISO 8601 with a time-zone offset, such as 2026-09-06T10:00:00+09:00
• Each measurement mapped to a numeric DFS binding in ACTIVE state, with a source unit matching the binding unit

Run the preview

1. Select a registered asset and upload the CSV.
2. Review the detected columns and row count.
3. Select the equipment, event ID, and event-time columns.
4. Map measurement columns to signals and enter each source unit.
5. Select Preview mapping results.
6. Review valid, duplicate, conflicting, and rejected rows. Correct time, identity, unit, or column selections and preview again.

Preview outcome

The preview analyzes only the uploaded file and does not write historical data. The data integration workflow controls the production import and overlap rules for live data.

Onboard a business dataset

Use New data onboarding when a published business objective requires files, worksheets, database tables, or API data.

Source inspection	Supported inputs	Preparation
File profiling	CSV, TSV, XLS, XLSX	File in a registered and authorized DFS location; each file is non-empty and no larger than 512 MiB
Dataset browsing	JDBC, Fabric, REST	A running connector instance with BROWSE capability and access to the selected data

1. Select the business objective, authorized source location, and evidence category.
2. Run Inventory source and confirm the included files, worksheets, or tables.
3. Run Profile dataset and review fields, types, missing values, candidate identifiers, and duplicates.
4. In the Decision workspace, confirm dataset purpose, field meaning, null rules, and relationships.
5. Resolve identity ambiguity and protected-field conflicts in the MDM review queue.
6. Run a dry run and inspect accepted, rejected, and quarantined counts together with proposed dataset, MDM, and fusion changes.
7. Have an approver review the release evidence, then have a release operator apply it.
8. Verify the active version and downstream application result.

Available business objectives and input formats come from the deployed release. If either list is empty, ask the application owner to prepare the business-data requirements or ask an administrator to register and authorize the source.

Maintain one asset identity across sources

Live messages, historical files, and business records for the same physical asset should resolve to the same confirmed MDM identity. Compare asset number, serial number, location, and source evidence before merging, splitting, or re-pointing records.

After the data steward records an identity decision, rerun the affected dry run or model check so the latest result includes that decision. For recurring deliveries, continue with Subsequent deliveries.